Am 30.01.2014 um 21:47 schrieb Charles Steinkuehler <char...@steinkuehler.net>:
> On 1/30/2014 2:14 PM, Michael Haberler wrote: >> >> Once ethernet level packet I/O is settled as fast enough, we can turn >> to add the minimal IP/UDP framing needed. This will be bare bones (no >> ping, arp, and other amenenities) but should have pretty much the >> same timing behavior and good enough for the task at hand. >> >> these are desk wisdoms, so handle with care. > > More "driving from behind the desk", but I've always thought the netmap > folks have a good approach: > > http://info.iet.unipi.it/~luigi/netmap/ yes, that's the piece I'd love to see being usable for us - unfortunately it seems this isnt going mainline in Linux but see the interesting comparison of PACKET_TX_RING and netmap here: http://queue.acm.org/detail.cfm?id=2103536 , it seems PACKET_TX_RING is considerably slower but still a big step forward - however, with stock drivers (I got the example packet-tx-ring.c to work even within vbox, i.e. without the netmap hardware restrictions): > • Gabor Gombas | Mon, 27 Feb 2012 22:48:58 UTC > I'd be very interested how netmap compares to PACKET_TX_RING/PACKET_RX_RING > as supported by Linux. The basic concept of using ring buffers shared between > the kernel and user space seems to be the same, so it would be interesting to > know how the performance of netmap compares to the existing solution. > • Luigi Rizzo | Tue, 28 Feb 2012 15:19:07 UTC > Gabor, i just tried PACKET_TX_RING and reached 1.85 Mpps at full cpu speed > (2.93GHz). > On the same hw, Netmap reaches the same performance at just 150MHz. The > comparison used same conditions (same hardware, 10 Gbit interface, ~1000 > packets per system call, packet buffers set in advance). > This is no surprise, because PACKET_TX_RING still uses skbufs in the device > driver, and this is a major source of overhead, as explained in the article > and in more details on the netmap page. Memory mapping is just one of the > many concepts that netmap uses to get performance. That confirms what Nicholas said: get around system call paths with dynamic memory allocation (IP stack, skbufs in the driver) I'll take on talking to the xenomai folks if this could be made to work from a Xenomai RT thread, it is not much missing - the only 'system call' (sendto) is really a notification to the driver to start pulling packets from the tx ring; rx ring operations seem to work without system calls. see also the related chat log; seems Michal has made significant progress already with stock socket calls: http://emc.mah.priv.at/irc/%23linuxcnc-devel/2014-01-30.html http://emc.mah.priv.at/irc/%23linuxcnc-devel/2014-01-31.html - Michael ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
