Re: [Xen-devel] netchannel vs MAX_SKB_FRAGS (Was: Re: [PATCH] xen/netfront: handle compound page fragments on transmit)

[annie li <annie.li@xxxxxxxxxx>]

On 2012-11-23 17:18, Ian Campbell wrote:
> On Fri, 2012-11-23 at 01:30 +0000, ANNIE LI wrote:
>   
> > It is hard to negotiate this between netfront and netback for different 
> > packets.
> >     
> You wouldn't negotiate for each packet, you would negotiate at start of
> day.
>
> You'd also need some sort of fallback for the case where you end up
> negotiating something smaller than the maximum your upper layer network
> stack might give you. I suppose you'd have to do segmentation somewhere
> along the line. (We have this problem now, and the Linux implementation
> just ignores it and drops the frames.)
What I am thinking is, this negotiation would be implemented during 
xenbus communication.
* netback provides its default value in xenstore
* netfront read out this value and compared this value with itself, then 
write back the larger one
  netback = netfront, use the same value
  netback > netfront, use netfront value and netfront does not need 
more slots
  netback < netfront, use netfront value and netfront does not need to 
do segmentation. But if netfront's total frag numbers exceed the max 
frag number of dom0(like linux's MAX_SKB_FRAGS), segmentation is needed 
for this kind of packets?
* netback read out the negotiated value from xenstore

It seems changing current netback to per-VIF is necessary(persistent 
grant benefit from it too), and every different vif in netback maintains 
its own value.
Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel