Re: [patch 0/7] CAN: Add new PF_CAN protocol family, try #3

Patrick McHardy wrote:

Urs Thuermann wrote:
  

quoted

* Use skb->iif instead of skb->cb to pass receiving interface from
  raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
    

skb->iif doesn't necessarily point to the incoming network device
as seen seen by netif_receive_skb, for layered devices it currently
always points to the first interface that received a packet.
  

This is exactly the intention.

Its so far also only used for traffic classification, please explain
how you're using it and what values it is set to on which paths.
  

As you might have seen in Documentation/networking/can.txt (hint, hint,
hint!) the CAN has no routing, no ARP, no MAC adressing and is a
broadcast only medium. So if there is (at least) any reasonable
addressing on CAN it consists of the CAN-frame's "CAN-Identifier" and
the CAN-bus this CAN-frame is sent/received on.

For this reason the information about the interface the CAN-frame has
been received on has to be made available to the user-application if it
needs this information. Until your hint about our skb->cb missusage, we
(successfully) transported this information inside skb->cb to
socket-level. But indeed skb->iif is the better (and in our opinion the
right) place to transport this information inside the skb to the
socket-level.

In both cases (receiving real CAN-frames from the CAN-netdev /
performing the loopback of CAN-frames) we set skb->iif to zero to let
netif_receive_skb() set the iif-value to the current skb->dev index. So
skb->iif is set to the first interface the CAN-frame is received on,
which is what we need & intended here.

Is it the right approach to let netif_receive_skb() set the iif-value or
should we better set this value on our own before invoking netif_rx()?

Best regards,
Oliver