[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] netchannel vs MAX_SKB_FRAGS (Was: Re: [PATCH] xen/netfront: handle compound page fragments on transmit)
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |