Hi,

In any cases, I understand that the classic linux nic driver needs  
modifications to be realtime. (refer to rtnet work)

because of the NAPI stack not really suitable for realtime.

So, I  understand that these modifications are not parts of the rt 
preeempt patch today.

for some nics, yes, there are some not well documented timeouts 
registers to be "hacked"  in order being realtime too.

Regards,
S.Ancelot

Le 03/05/2017 à 23:33, Jeff Epler a écrit :

In LinuxCNC, we are successfully using rt preempt for realtime
networking.  You can find the code in our public git:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/hm2_eth.c
(GPL2+ license).  This talks to an FPGA board from Mesa Electronics,
which is running its own embedded realtime software stack.

Depending on the setup, this generally consists of 2 UDP packets
transmitted + 1 packet received, at a repetitive rate between 500Hz and
4kHz, with most users selecting 1kHz as far as we're aware.  The packets
aren't that big overall, without looking I bet it's under 1kB per period
all told.  (so the bandwidth utilization is not high)

On the Linux end we are generally using a dedicated gigabit NIC, and my
testing personally has been with Intel PCI-E nics like 82574L.  Most
users attach a single FPGA board (that board has a 100-megabit NIC) but
it's also possible to attach several boards via a dedicated gigabit
switch.

(The packet data consists of information from a CNC machine such as
motor position and other machine state, and commands to the machine
consist of things like motor torque commands or step waveform frequency
commands; LinuxCNC closes the position loop and performs other machine
logic)

As usual, not all mainboards and NICs are suitable, but we certainly
have success with specific Intel NICs. (and maybe some realteks?)

There are some tunables like RX IRQ coalesce that need to be, er, tuned
but I don't have that info on hand and it looks like it isn't in our
documentation. :(

I wish the tricks like manual ARP pinning and firewall manipulation
weren't necessary, but in our situation they seem to be somewhere
between helpful and necessary.  In particular, needing to ARP the other
NIC is not great for latency.

I've used hm2_eth with a range of RT kernels from 3.2 to 4.9 (usually
debian -rt kernels).

Disclaimer: I was compensated for the work I'm describing here

Jeff