Re: [Xen-devel] XEN_NETIF_NR_SLOTS_MIN

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.09.15 at 16:56, <wei.liu2@xxxxxxxxxx> wrote:
> On Fri, Sep 04, 2015 at 06:50:45AM -0600, Jan Beulich wrote:
>> Wei,
>> 
>> coming back to commit 723a375f4e introducing this constant along
>> with some commentary: First of all - why 18 when in old Linux kernels
>> MAX_SKB_FRAGS is 18 and the head usually requires another slot?
> 
> That indeed didn't count the head slot, which is handled separately. It
> also doesn't include meta slots.
> 
> Maybe the comment needs to be updated to "slots that contain actual
> data"?

That would take care of the meta slots, but the head to me also is
"actual data".

>> And then - why mostly/only for the (guest) TX path? Don't we have
>> two compatibility issues:
>> 1) old netfront (max 18 frags) sending via new netback (max 17
>> frags)
> 
> That's handled by netback by consolidating frags.

Right - that's the TX path that the description in netif.h refers to.

>> 2) old netback (max 18 frags) handing received packets to new
>> frontend (max 17 frags)
> 
> That's fine because 18 > 17.

Exactly because of 18 > 17 this is not fine: How would netfront fit
18 slots handed to it by netback into 17 frags without special
adjustments?

>> I.e. shouldn't modern netback be capable to (guest) send at least
>> 19 slots despite there only being 17 frags, and shouldn't similarly
> 
> It does -- as said above, the head and extra slots are not counted
> against that limit.
> 
>> modern netfront be able to receive at least 19 slots? In the latter
>> case - if not, how should netback guess at what number of slots it
>> can safely forward? (Yes, I am aware of David's 1650d5455b
> 
> Note that slot != frag. I admit netif.h conflates the two concepts in a
> bad way. I think that's due to netback has evolved a lot overtime.
> 
> I'm pretty sure there is check in netback to not overrun the ring by
> using too many slots.
> 
> If you're talking about number of frags, it's not on protocol level.
> Linux netfront is able to consolidate several slots into reasonable
> number of frags and make sure the number of frags won't exceed limit.
> See xennet_fill_frags.

That's too late - xennet_get_responses() would have rejected such
a packet already afaict (error message "Too many slots").

>> relying on hypervisor side improvements available only in 4.6, i.e.
>> while in general considering this a reasonable approach, I'm not
>> sure this should be done unconditionally, and hence I'm trying to
>> figure reasonable criteria of when to do this on older hypervisors.)
> 
> I think with my above explanation it should be safe for you to not
> include 1650d5455b.

Without an equivalent of David's change I don't see how netfront
would cope with what _old_ netback may hand it.

Jan


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