Re: [Xen-devel] [PATCH 5/6] xen-netback: coalesce slots before copying

[James Harper <james.harper@xxxxxxxxxxxxxxxx>]

> 
> On 26/03/13 10:52, James Harper wrote:
> >>> 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".
> >>
> >
> > I've obviously not been clear enough here... GPLPV stopped counting
> > at 20 (only needed to know if <20 or not). Windows itself can submit
> > a packet to NDIS with hundreds of buffers. It doesn't really matter
> > if it's 21 or 1021, I just didn't want to be misquoted.
> 
> This still isn't clear.  What's the maximum number of ring entries that
> GPLPV driver will use per packet?  Are you saying it's 20?  If so how
> has the GPLPV driver ever worked well with Linux's netback (with its
> historical limit of 18)?
> 

GPLPV will limit to 19, which I thought was the historic Linux limit but 
obviously not. I'd better look in to that.

I added a debug statement to catch what Windows would give to GPLPV, and it 
seemed that the maximum was 20, but then I double checked and GPLPV only needs 
to know if there are >19 frags or not, so it stops counting at 20. The actual 
number Windows will use internally is not limited so coalescing is required, 
and no sane amount of bumping up the Linux limit will reduce the requirement 
that a Windows driver will need to coalesce.

James


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