netdev - Re: TCP communication for raw image transmission

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]

Date:	Wed, 4 Jan 2012 12:16:56 +0100
From:	Jean-Michel Hautbois <jhautbois@...il.com>
To:	David Laight <David.Laight@...lab.com>
Cc:	netdev@...r.kernel.org
Subject: Re: TCP communication for raw image transmission

2012/1/4 David Laight <David.Laight@...lab.com>:
>
>> I am currently working on a way to send raw images (~400*300 YUV
>> 4:2:0) at a relative high speed (raw image and not compressed image
>> due to specific codec issues).
>> This would represent about 57MBps/sec on a 100Mbps ethernet link.
>> This link is direct, nothing else will pass through it.
> ...
>> I was thinking about using TCP socket (of course) ...
>
> I'm not sure you get any benefit from using TCP (over UDP).
> If any packets are lost (which on a dedicated network they
> shouldn't be) then you probably can't stand the restransmit
> delays - especially if the losses are systemic and repeated
> in which case you'll occaisionally end up with very slow
> throughput (when not enough packets are sent for the
> out-of-sequence receives to request retransittions).

UDP is interesting for the fast path (you mention it later) but it has
some drawbacks, with one being packet loss.
Today, it is a dedicated link, but maybe will I use a switch also, and
the problem would exist.
I can't say (I will try tomorrow) if this would be really more
efficient on my board BTW.
If this is a HW issue then, UDP or TCP will be limited in the same way.

> The TCP stack also has a series of 'features' that will
> reduce the attainable throughput for this kind of traffic:
> 1) Nagle - easily turned off.
> 2) Slow start - only a global flag
> 3) Delayed acks - make 'slow start' more of a problem.
>
> The code paths for UDP (sender and receiver) will be
> much shorter, although you'll probably need to ensure
> there is adequate buffering.
>
> Also, it should be fairly easy to directly send the UDP
> packets from withing the kernel completly bypassing the
> normal UDP+IP parts of the network stack!
> I know some people have done that completely in hardware
> on some FPGA systems with slow cpus.

You mean using a layer 2 protocol with specific ethertype and raw
sockets for instance ?

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