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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-11-23 at 01:30 +0000, ANNIE LI wrote:
> 
> On 2012-11-21 0:04, Ian Campbell wrote:
> > Limiting to just xen-devel folks.
> >
> > On Tue, 2012-11-20 at 15:54 +0000, Ian Campbell wrote:
> >
> > 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.
> 
> Yes, MAX_SKB_FRAGS is max frag number, not max slot number required.
> But I am not so clear about the whole implementation here. Does it mean 
> netfront/netback uses something like MAX_SKB_FRAGS*SLOTS_PER_FRAG?

I suppose that's one way of looking at it. SLOTS_PER_FRAG is 1 in the
current Linux implementation.

But really MAX_SKB_FRAGS (and the concept of frags generally, although I
suspect most OSes have something equivalent in their SG mechanism) is a
Linux-ism which has leaked into the protocol. A non-Linux front or
backend might support more or less and have to jump through hoops to
remain compatible with the Linux versions.

So actually maybe it's better to think in terms of MAX_SLOTS_PER_FRAME
with no reference to frags at all. Currently MAX_SLOTS_PER_FRAME ==
MAX_SKB_FRAGS for the Linux implementation of front/back. This has
leaked into the protocol, since Linux is the most commonly used backend,
and so we've placed additional requirements onto non-Linux front and
backends.

>  and 
> SLOTS_PER_FRAG can be adjusted based on different situation? If netfront 
> and netback negotiate this value, then xenstore key feature is required, 
> right?

Yes.

> As mentioned in another compound page fragments patch, for non-compound 
> page, this value could be 64K/PAGE_SIZE + 1, but if taking account into 
> compound page, the worse case is around 48 slots(in 1+4096+1 case).

That's for order 5 compound pages, 

> It is hard to negotiate this between netfront and netback for different 
> packets.

You wouldn't negotiate for each packet, you would negotiate at start of
day.

You'd also need some sort of fallback for the case where you end up
negotiating something smaller than the maximum your upper layer network
stack might give you. I suppose you'd have to do segmentation somewhere
along the line. (We have this problem now, and the Linux implementation
just ignores it and drops the frames.)

Ian.

> 
> Thanks
> Annie
> > I don't have time for either of those unfortunately
> >
> > Ian.
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel



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