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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140411063021.GH30855@1wt.eu>
Date:	Fri, 11 Apr 2014 08:30:21 +0200
From:	Willy Tarreau <w@....eu>
To:	David Miller <davem@...emloft.net>
Cc:	eric.dumazet@...il.com, ezequiel.garcia@...e-electrons.com,
	netdev@...r.kernel.org, thomas.petazzoni@...e-electrons.com,
	gregory.clement@...e-electrons.com, simon.guinot@...uanux.org,
	tawfik@...vell.com, alior@...vell.com
Subject: Re: [PATCH 0/3] mvneta: software TSO implementation

On Fri, Apr 11, 2014 at 02:20:06AM -0400, David Miller wrote:
> From: Willy Tarreau <w@....eu>
> Date: Fri, 11 Apr 2014 07:48:47 +0200
> 
> > I also tried to find how to do this for mv643xx_eth a few years ago
> > based on other drivers (eg: tilegx) and failed to find anything
> > common. At this level, we're really playing with the NIC's descriptors,
> > and many of them have different capabilities (eg: HW checksums for all
> > frames, VLAN or none, etc...). I don't really see how this could be
> > factorized, and since many NICs do support TSO, I'm not convinced by
> > the effort.
> 
> I wanted to hook this into the NIU driver as well, which also lacks
> TSO support.
> 
> The descriptor and checksum part is chip specific, but the segmentation
> of the buffer segments, calculating the number of necessary descriptors,
> etc. absolutely is not.

Agreed.

> Please work on finding a suitable abstraction, it's possible.

Do you think for example that having an xmit_tso() function which would
iterate over all segments and call something like :
   ->build_hdr()
   ->build_data()
   ->unroll_all()

would be sufficient ?

I fear that relying on function pointers in the inner loop can
significantly offset the CPU savings, but it could be attempted.

I think that the fact you want to do it for NIU is a good opportunity
to try to do it the right way in the most generic mode, but we'll
surely need your help on this!

Willy

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ