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

[Xen-devel] XEN_NETIF_NR_SLOTS_MIN



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?
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)
2) old netback (max 18 frags) handing received packets to new
frontend (max 17 frags)
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
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
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.)

Thanks, 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®.