On Tue, Mar 26, 2013 at 09:16:10AM +0000, Paul Durrant wrote:

quoted

quoted

It's not clear why 19 or 20 were suggested as possible values.  I
checked back to 2.6.18 and MAX_SKB_FRAGS there is (65536/PAGE_SIZE
+

2)

Because the check is >= MAX_SKB_FRAGS originally and James Harper
told me that "Windows stops counting on 20".

For the Citrix PV drivers I lifted the #define of MAX_SKB_FRAGS from
the dom0 kernel (i.e. 18). If a packet coming from the stack has more

That means Citrix PV drivers cannot run on a vanilla kernel backend
because upstream MAX_SKB_FRAGS now is 17. The scope of the patch is to
fix this sort of problems without touching frontend because it is
impossible for us to fix every frontend in the world.

than that number of fragments then it's copied and coalesced. The
value advertised for TSO size is chosen such that a maximally sized
TSO will always fit in 18 fragments after coalescing but (since this
is Windows) the drivers don't trust the stack to stick to that limit
and will drop a packet if it won't fit.

It seems reasonable that, since the backend is copying anyway, that it
should handle any fragment list coming from the frontend that it can.
This would allow the copy-and-coalesce code to be removed from the
frontend (and the double-copy avoided). If there is a maximum backend
packet size though then I think this needs to be advertised to the
frontend. The backend should clearly bin packets coming from the
frontend that exceed that limit but advertising that limit in xenstore
allows the frontend to choose the right TSO maximum size to advertise
to its stack, rather than having to make it based on some historical
value that actually has little meaning (in the absence of grant
mapping).

The historical is choosen based on the idea that it should cope with all
known frontend limits and leave a bit more space for frontends that
slightly cross the line. Advertising through Xenstore is the future plan
as it cannot be done without modifying frontend.


Wei.