Re: [Xen-devel] netback grant copying issues

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Sep 07, 2015 at 09:23:59AM -0600, Jan Beulich wrote:
> >>> On 07.09.15 at 17:10, <wei.liu2@xxxxxxxxxx> wrote:
> > On Mon, Sep 07, 2015 at 09:03:12AM -0600, Jan Beulich wrote:
> >> >>> On 07.09.15 at 16:47, <wei.liu2@xxxxxxxxxx> wrote:
> >> > With that in mind, even MAX_SKB_FRAGS + 1 is not enough. It would be
> >> > MAX_SKB_FRAGS + 64K / PAGE_SIZE, i.e. we count the most extreme
> >> > situation that we have 63K data in SKB, and 1 byte in each frag.
> >> 
> >> No, every component (head + every frag) can contribute
> >> exactly one copy operation to a RX ring slot (larger heads, just
> >> like larger frags) would get copied into multiple RX ring slots.
> >> 
> > 
> > I think you misunderstand copy_op slot vs RX ring slot.  The limitation
> > rs for copy_op slots, not RX ring slots. Note that multiplication of
> > XEN_NETIF_RX_RING_SIZE.
> > 
> > The skb header data len is not limited to one 4K page (4K because that's
> > what xen grant table interface supports), netback will break skb header
> > data into multiple copy_op slots.
> 
> But in that case it will not only use multiple copy_op slots, but also
> copy into multiple RX slots. I.e. still - per RX slot there can only be
> MAX_SKB_FRAGS+1 copy_op slots.
> 
> Two examples may help
> 
> head  1 byte
> frag1 1 byte
> ...
> fragN 1 byte
> 
> will need N+1 copy slots and one RX slot.
> 
> head  8k              2 copy slots, 2 RX slots
> frag1 1 byte          3rd copy slot, 3rd RX slot
> ...
> fragN 1 byte          N+2nd copy slot, 3rd RX slot
> 

Yes, indeed. I missed that. I should have notice this when I wrote "what
xen grant table interface supports".

> Jan

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