[Xen-devel] netchannel vs MAX_SKB_FRAGS (Was: Re: [PATCH] xen/netfront: handle compound page fragments on transmit)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

Limiting to just xen-devel folks.

On Tue, 2012-11-20 at 15:54 +0000, Ian Campbell wrote:
> The use of MAX_SKB_FRAGS is a bit misleading here, it's really the max
> number of slots which the other end will be willing to receive as a
> single frame (in the Ethernet sense), as defined by the PV protocol.
> It happens to be the same as MAX_SKB_FRAGS (or it is at least
> MAX_SKB_FRAGS, I'm not too sure). 

This highlights a couple of issues, the main one is that implicitly
including MAX_SKB_FRAGS in the PV net protocol is just madness. It can
and has changed in the past. Someone really needs to (retroactively)
figure out what a sensible default minimum which front and back must
support is and use it in the front and backends instead of
MAX_SKB_FRAGS. Probably something derived from the existing 64K limit
(Linux has used 17 and 18 as MAX_SKB_FRAGS in the past).

Then perhaps implement a feature-flag to allow front and backends to
negotiate something bigger if they like.

It might also be interesting for front and backends to coalesce multiple
ring slots into compound pages.

I don't have time for either of those unfortunately

Ian.


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