[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |