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.net \
--cc=davem@davemloft.net \
--cc=j.hadi123@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=oliver.hartkopp@volkswagen.de \
--cc=oliver@hartkopp.net \
--cc=tglx@linutronix.de \
--cc=urs.thuermann@volkswagen.de \
--cc=urs@isnogud.escape.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.