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]

Message-ID: <196961493.20140328114238@eikelenboom.it>
Date:	Fri, 28 Mar 2014 11:42:38 +0100
From:	Sander Eikelenboom <linux@...elenboom.it>
To:	David Laight <David.Laight@...LAB.COM>
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


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.

However since the calculated max_needed_slots grow so fast (most of the time unnecessary, i put a printk in there for that and it was quite often more than 5 slots off),
that is also wasteful and it uses a more complex calculation.


>         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