On Sun, Jul 12, 2015 at 12:15 PM, Oliver Hartkopp <socket...@hartkopp.net> wrote: > Hello Eric, > > On 07/11/2015 06:35 AM, Eric Dumazet wrote: >> On Fri, 2015-07-10 at 22:36 +0200, Oliver Hartkopp wrote: > >>> Hm. Doesn't sound like a good solution when there's a difference between >>> NAPI >>> and non-NAPI drivers in matters of OOO, right? >> >> Isn't OOO a problem for you ? Then you either have to : >> >> 1) Use a single CPU to handle IRQ from the device >> 2) Use NAPI >> > > See below ... > >>> What about checking in netif_rx() if the non-NAPI driver has set a hash (aka >>> the driver is OOO sensitive)? >>> And if so we could automatically set rps_cpus for this interface in a way >>> that >>> all CPUs are enabled to take skbs following the hash. >> >> Wow, netif_rx() is packet processing fast path, certainly not the place >> to add controlling path decisions. > > My only requirement is to be able to pick CAN frames (contained in skbs) from > the socket in the same order they have been received. > >> Please convert your driver to NAPI. You might then even benefit from >> GRO. > > Just some remarks about CAN and CAN frames as you suggest GRO which is > completely pointless for CAN. > > CAN frames have a 11 or 29 bit CAN Identifier (no MAC but content addressing) > and 0 to 64 bytes of payload. Therefore the MTU for CAN interfaces is 16 or 72 > byte (see struct can(fd)_frame). Each skbuff contains a single CAN frame. > > There are CAN controllers which have a FIFO for up to 32 CAN frames, e.g. > flexcan.c which also implements NAPI. Others (e.g. sja1000.c) don't have any > FIFO and the reading of the CAN frame from the memory mapped registers needs > to be processed in the irq context instantly. So 'fast path' netif_rx() is > reasonable, right? > > So why is it not possible to pass netif_rx() skbs from a specific CAN network > interface to whatever queue where they are processed in order? > > E.g. with > > skb_set_hash(skb, dev->ifindex, PKT_HASH_TYPE_L2); > > and > > echo f > /sys/class/net/can0/queues/rx-0/rps_cpus > > I get properly ordered CAN frames - even with netif_rx() processed skbs. I > just want to have this stuff to be enabled by default for CAN interfaces to > kill the OOO frame issue. > If you really must process the CAN FIFO in the hard interrupt then create a private sk_buf queue. In the interrupt, dequeue from FIFO and enqueue on the sk_buf queue. Then schedule NAPI, and when that runs process the sk_buf queue calling call netif_receive_skb for each enqueued skb. Pretty simple actually :-)
> Regards, > Oliver > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
