netdev - RE: Can I limit the number of active tx per TCP socket?

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]

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