netdev - RE: [net-next v2 02/19] i40e: simplify txd use count calculation

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] [day] [month] [year] [list]

Date:   Thu, 8 Dec 2016 01:09:35 +0000
From:   "Duyck, Alexander H" <alexander.h.duyck@...el.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
CC:     "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "Williams, Mitch A" <mitch.a.williams@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "jogreene@...hat.com" <jogreene@...hat.com>,
        "guru.anbalagane@...cle.com" <guru.anbalagane@...cle.com>
Subject: RE: [net-next v2 02/19] i40e: simplify txd use count calculation

> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@...il.com]
> Sent: Wednesday, December 7, 2016 5:04 PM
> To: Duyck, Alexander H <alexander.h.duyck@...el.com>
> Cc: Kirsher, Jeffrey T <jeffrey.t.kirsher@...el.com>; davem@...emloft.net;
> Williams, Mitch A <mitch.a.williams@...el.com>; netdev@...r.kernel.org;
> nhorman@...hat.com; sassmann@...hat.com; jogreene@...hat.com;
> guru.anbalagane@...cle.com
> Subject: Re: [net-next v2 02/19] i40e: simplify txd use count calculation
> 
> On Thu, 2016-12-08 at 00:35 +0000, Duyck, Alexander H wrote:
> 
> > Well there ends up being a few aspects to it.  First we don't need the
> > precision of a full 64b inverse multiplication, that is why we can get
> > away with multiple by 85 and shift.  The assumption is we should never
> > see a buffer larger than 64K for a TSO frame.  That being the case we
> > can do the same thing without having to use a 64b value which isn't an
> > option on 32b architectures.
> >
> > So basically what it comes down to is dealing with the "optimized for
> > size" kernel option, and 32b architectures not being able to do this.
> > Arguably both are corner cases but better to deal with them than take
> > a performance hit we don't have to.
> 
> ok ok ;)
> 
> Too bad the 65536 value is accepted, (is it ?) otherwise
> 
> unsigned int foo(unsigned short size)
> {
> 	return size / 0x3000;
> }
> 
> -> generates the same kind of instructions, with maybe a better
> precision.
> 
> foo:
> 	movzwl	%di, %eax
> 	imull	$43691, %eax, %eax
> 	shrl	$29, %eax
> 	ret

I haven't ever looked all that closely.  I'm assuming the frame size can probably exceed by at least ETH_HLEN - 1 since the IP header length can theoretically reach 64K - 1 before we are maxed out.

We don't really need the extra precision anyway.  We will be off by 1 most likely anyway in many cases since the actual hardware can handle up to 16K - 1 in either the first and/or last buffer of any series since the actual limit is the 14 bits in the Tx descriptor for reporting the buffer length and we try to keep the split between buffers 4K aligned.

- Alex