On Wed, 18 15:13 , Geoff Steckel wrote: > Markus wrote: >> Good evening, >> I'm setting off for writing prototype code for an imaging >> application. For this reason, I'm in need of an extremely fast way to >> transport large amounts of UDP data to a userland application. A socket >> implementation does not perform very well, which is the >> reason why I'm looking for a better solution to minimize processing time. >> My initial idea was to already filter the traffic with bpf and only hand >> the datagrams (or parts of them) I really want out of kernel space. > > Hi, > Could you forward or post the profile data that shows the hot > spot(s) in the kernel? It would be very instructive. > thanks > geoff steckel
Hi Geoff, this sounds as if you would prefer sockets if possible. Is there a reason why you would reject using bpf directly? I guess for testing the socket approach you could pretty much take any UDP client and throw datagrams on it over a gigabit link (load will be around 30 fps with 3 MB each image frame + headers). The client system does no disk I/O btw, it's just getting the data from the socket and, in its simplest form, hands it over to a display. Unfortunately I got neither some decent computer hardware here at my flat nor a device that could pump out the amount of packets I want to produce via eg. tcpreplay (or simply a camera). I will however try to get some data before I'm heading off for travelling 4 weeks this weekend if you're interested in it. All the best, /Markus
