Am 31.01.2014 um 15:24 schrieb Kenneth Lerman <kenneth.ler...@se-ltd.com>:
> 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 would guess it helps a bit. It doesnt cut out the usage of skbufs at the driver level; it does however cut out the usage of skbufs in the data path down _to_ the driver (like the UDP and IP layers, header processing etc); the sendto() which is used in the packet-tx-ring.c example doesnt pass the buffer, rather the buffer address within the ring buffer. So that would take out skbuf usage for headers and maybe something I overlook. I need to read up the syscall path of that sendto; or maybe just ftrace it. Desk guess it just wraps the ringbuffer into an skbuf and tickles the driver send side. If that is the case, it's bound to be a tad faster because the IP+UDP layers need not to be traversed. The driver blocking on skbuf allocation could still a problem in theory. > > 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. that's an interesting idea - leaving the kernel IP stack in charge to do setup - adress assignment, bootp etc, and the to grab the interface for RT use. Maybe take the ARP table at that point and use the entries in preparing the IP frame for ethernet. It would greatly help setup and debugging because everything is standard until the RT thread takes in charge it should be rather easy to trace packets with rtapi_print(). - Michael > > 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 ------------------------------------------------------------------------------ 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
