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] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D0F6D7994@AcuExch.aculab.com>
Date:	Fri, 7 Mar 2014 16:39:38 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Eric Dumazet' <eric.dumazet@...il.com>
CC:	'Neal Cardwell' <ncardwell@...gle.com>,
	Rick Jones <rick.jones2@...com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: Can I limit the number of active tx per TCP socket?

From: Eric Dumazet 
> On Fri, 2014-03-07 at 14:35 +0000, David Laight wrote:
> 
> > Only the one connection between the two IP addresses is carrying this data.
> > Other connections carry other traffic that has entirely different
> > characteristics.
...
> By letting the stack doing optimal aggregation, you'll have no overhead
> an perfect pacing (using high resolution timer)

I don't need 'perfect pacing', and indeed it wouldn't work.
I'm also actually sending from within the kernel, so high resolution
timers aren't a big problem.

The code also has a (per socket) kernel thread dedicated to the
sends (partially because we didn't work out how to do the equivalent
of poll from within the kernel), but doing the socket send (and
receive) from separate kernel threads helps share the load between
cpus - most of the rest of the protocol stack runs as a single
kernel thread to simplify locking.

Fortunately I'm fairly sure that our customers don't try to use
the same traffic patterns as I do in testing.

We do have customers sending very large numbers of packets through
sctp (I believe 15000 data chunks/sec).
I might have to look at that code to see if anything can be
done to get multiple data chunks into a single ethernet packet.
Since each send() generates a separate data chunk I can't use sendv()
to merge fragments (as I do for tcp).

	David

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ