On Fri, Jul 20, 2007 at 03:31:01PM +0200, M. Koehrer wrote: > Hi, > > thanks for the feedback. I had a closer look at the receive path of an Ethernet frame. > The driver (e1000 in my case) receives the raw frame and calls netif_rx. > >From netif_rx the sk_buff is passed on to netif_rx_schedule and here a raise_soft_irqoff(NET_RX_SOFTIRQ) > is called to trigger the task that does the remaining parts of the reception. > Even if I use a AF_PACKET / AF_RAW socket, it will be handled by the NET_RX_SOFTIRQ task. > As this task is not running in real time priority, I loose real time behaviour. > > Within netif_rx there is a call to netpoll_rx which could be used as a kind filter to > separate interesting packets. However, currently netpoll_rx is used by the netconsole which allows > to register exactly one UDP per device that is taken into account. > I can not handle a real time network. Neither I do have a inteface to user space to the netconsole. > One approach could be to implement something similar to netpoll_rx that is used as switch > to separate standard Ethernet frames and frames that are treated as real time relevant. > In this case something similar to netif_rx_schedule is needed that calls a real time priority > irq thread like NET_RX_SOFTIRQ... > > Any comments or feedback on this is highly welcome... > > Thanks a lot > > Mathias > This is exactly why previous posters were telling you that ethernet was not really what you were looking for if you want hard real time behavior. Perhaps you should look into the RtNet project or something simmilar: http://sourceforge.net/projects/rtnet/ Regards Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@xxxxxxxxxxxxx *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
