[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] netback grant copying issues



>>> 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

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.