netdev - RE: [Xen-devel] [PATCH net v2 1/3] xen-netback: remove pointless clause from if statement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 28 Mar 2014 11:11:24 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Sander Eikelenboom' <linux@...elenboom.it>
CC:	'Paul Durrant' <Paul.Durrant@...rix.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Wei Liu <wei.liu2@...rix.com>,
	Ian Campbell <Ian.Campbell@...rix.com>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>
Subject: RE: [Xen-devel] [PATCH net v2 1/3] xen-netback: remove pointless
 clause from if statement

From: Sander Eikelenboom
> Friday, March 28, 2014, 11:35:58 AM, you wrote:
> 
> > From: Paul Durrant
> >> > A reasonable high estimate for the number of slots required for a specific
> >> > message is 'frag_count + total_size/4096'.
> >> > So if that are that many slots free it is definitely ok to add the message.
> >> >
> >>
> >> Hmm, that may work. By total_size, I assume you mean skb->len, so that calculation is based on an
> >> overhead of 1 non-optimally packed slot per frag. There'd still need to be a +1 for the GSO 'extra'
> >> though.
> 
> > Except I meant '2 * frag_count + size/4096' :-(
> 
> > You have to assume that every fragment starts at n*4096-1 (so need
> > at least two slots). A third slot is only needed for fragments
> > longer that 1+4096+2 - but an extra one is needed for every
> > 4096 bytes after that.
> 
> He did that in his followup patch series .. that works .. for small packets
> But for larger ones it's an extremely wasteful estimate and it quickly get larger than the
> MAX_SKB_FRAGS
> we had before and even to large causing stalls. I tried doing this type of calculation with a CAP of
> the old  MAX_SKB_FRAGS calculation and that works.

I'm confused (easily done).
If you are trying to guess at the number of packets to queue waiting for
the thread that sets things up to run then you want an underestimate.
Since any packets that can't actually be transferred will stay on the queue.
A suitable estimate might be max(frag_count, size/4096).

The '2*frag_count + size/4096' is right for checking if there is enough
space for the current packet - since it gets corrected as soon as the
packet is transferred to the ring slots.

	David



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html