On 1/31/2014 4:53 AM, Michael Haberler wrote: > 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 It's important to note that netmap is mainly to increase throughput; not decrease latency. That's done by using a ring buffer and limiting the number of entries into the kernel. That doesn't help us because we will never have more than one item in the ring buffer at a time. Our model is to loop over writing, waiting for a response, process the response, and back to the beginning.
I'm a great believer in just using raw ether reads and writes. The benefit of TCP is that it recovers from dropped packets. That does NO good in a real time system. The benefit of UDP is that it assembles ether frames into larger packets. The 1500 or so bytes provided by a standard ether frame should be sufficient for what we do. (If not, we might find some hardware that provides for jumbo frames -- 9000 bytes). The benefit of IP is that it provides a neat addressing resolution scheme (MAC address are a pain) and routing. We should never be using routers or switches in our systems. If we want the benefits of DHCP to handle our addressing, we could run DHCP, ARP, RARP, IP (some of which might be relevant) prior to going real time. We could use that to do our MAC lookup. After that, raw ether frames would be fine. I've used raw ether in the past and it works just fine. Just some thoughts. Regards, Ken > > 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 ------------------------------------------------------------------------------ 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
