From: Patrick McHardy <kaber@trash•net>
To: Oliver Hartkopp <oliver@hartkopp•net>
Cc: Urs Thuermann <urs@isnogud•escape.de>,
David Miller <davem@davemloft•net>,
Thomas Gleixner <tglx@linutronix•de>,
Oliver Hartkopp <oliver.hartkopp@volkswagen•de>,
Urs Thuermann <urs.thuermann@volkswagen•de>,
netdev@vger•kernel.org, j.hadi123@gmail•com
Subject: Re: [patch 0/7] CAN: Add new PF_CAN protocol family, try #3
Date: Fri, 22 Jun 2007 18:23:50 +0200 [thread overview]
Message-ID: <467BF796.9080900@trash.net> (raw)
In-Reply-To: <467BF184.8040109@hartkopp.net>
Oliver Hartkopp wrote:
> Patrick McHardy wrote:
>
>> Urs Thuermann wrote:
>>
>>
>>> * 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.
>
Lets hear Jamal's opinion on this, to be honest I never understood
how exactly it is supposed to be used.
> 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()?
>
netif_receive_skb is meant to be used as a default, the driver can
override this if it makes sense. If you touch it anyway you might
as well set it to the final value.
next prev parent reply other threads:[~2007-06-22 16:24 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-22 3:44 [patch 0/7] CAN: Add new PF_CAN protocol family, try #3 Urs Thuermann
2007-06-22 3:44 ` [patch 1/7] CAN: Allocate protocol numbers for PF_CAN Urs Thuermann
2007-06-22 3:44 ` [patch 2/7] CAN: Add PF_CAN core module Urs Thuermann
2007-06-22 3:44 ` [patch 3/7] CAN: Add raw protocol Urs Thuermann
2007-06-22 3:44 ` [patch 4/7] CAN: Add broadcast manager (bcm) protocol Urs Thuermann
2007-06-22 3:44 ` [patch 5/7] CAN: Add virtual CAN netdevice driver Urs Thuermann
2007-06-22 11:02 ` Patrick McHardy
2007-06-22 12:22 ` Urs Thuermann
2007-06-22 12:38 ` Patrick McHardy
2007-06-23 12:05 ` Oliver Hartkopp
2007-06-23 12:52 ` Patrick McHardy
2007-06-23 15:13 ` Oliver Hartkopp
2007-06-23 16:25 ` Patrick McHardy
2007-06-23 16:42 ` Oliver Hartkopp
2007-06-23 17:13 ` Patrick McHardy
2007-07-04 11:37 ` Urs Thuermann
2007-07-04 14:01 ` Patrick McHardy
2007-07-09 11:37 ` Urs Thuermann
2007-07-09 14:18 ` Patrick McHardy
2007-07-09 15:27 ` Oliver Hartkopp
2007-07-11 19:41 ` Oliver Hartkopp
2007-07-11 22:52 ` Patrick McHardy
2007-07-16 6:05 ` Oliver Hartkopp
2007-07-16 8:37 ` David Miller
2007-07-16 13:08 ` Patrick McHardy
2007-07-16 16:27 ` Oliver Hartkopp
2007-07-16 13:07 ` Patrick McHardy
2007-07-16 16:00 ` Oliver Hartkopp
2007-06-23 21:01 ` David Miller
2007-06-23 21:44 ` Oliver Hartkopp
2007-06-24 16:51 ` [CAN] [RFC] skb->iif usage and vcan driver background Oliver Hartkopp
2007-06-25 10:37 ` Patrick McHardy
2007-06-25 14:50 ` Oliver Hartkopp
2007-06-23 20:51 ` [patch 5/7] CAN: Add virtual CAN netdevice driver David Miller
2007-06-23 21:49 ` Oliver Hartkopp
2007-06-22 3:44 ` [patch 6/7] CAN: Add maintainer entries Urs Thuermann
2007-06-22 3:44 ` [patch 7/7] CAN: Add documentation Urs Thuermann
2007-06-22 12:34 ` [patch 0/7] CAN: Add new PF_CAN protocol family, try #3 Patrick McHardy
2007-06-22 15:57 ` Oliver Hartkopp
2007-06-22 16:23 ` Patrick McHardy [this message]
2007-06-22 17:19 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=467BF796.9080900@trash.net \
--to=kaber@trash$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=j.hadi123@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=oliver.hartkopp@volkswagen$(echo .)de \
--cc=oliver@hartkopp$(echo .)net \
--cc=tglx@linutronix$(echo .)de \
--cc=urs.thuermann@volkswagen$(echo .)de \
--cc=urs@isnogud$(echo .)escape.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox