From: Jiri Pirko <jiri@resnulli.us>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Ido Schimmel <idosch@idosch.org>,
Florian Fainelli <f.fainelli@gmail.com>,
netdev@vger.kernel.org, davem@davemloft.net,
bridge@lists.linux-foundation.org, stephen@networkplumber.org,
vivien.didelot@savoirfairelinux.com, jiri@mellanox.com,
idosch@mellanox.com
Subject: Re: [RFC net-next 0/3] net: bridge: Allow CPU port configuration
Date: Tue, 22 Nov 2016 23:08:59 +0100 [thread overview]
Message-ID: <20161122220859.GF1819@nanopsycho> (raw)
In-Reply-To: <20161122174829.GD14947@lunn.ch>
Tue, Nov 22, 2016 at 06:48:29PM CET, andrew@lunn.ch wrote:
>Hi Ido
>
>> First of all, I want to be sure that when we say "CPU port", we're
>> talking about the same thing. In mlxsw, the CPU port is a pipe between
>> the device and the host, through which all packets trapped to the host
>> go through. So, when a packet is trapped, the driver reads its Rx
>> descriptor, checks through which port it ingressed, resolves its netdev,
>> sets skb->dev accordingly and injects it to the Rx path via
>> netif_receive_skb(). The CPU port itself isn't represented using a
>> netdev.
>
>With DSA, we have a real physical ethernet network interface for the
>'cpu' port. It connects to one of the ports of the switch. Frames on
Every port should be visible as a netdevice, including cpu port.
Would it make sence to have representors for those?
>this interface have an extra header, indicating which switch port it
>came from, and we do a similar resolving it to a slave netdev, strip
>of the header and injecting it into the receiver path via
>netif_receive_skb().
>
> Andrew
next prev parent reply other threads:[~2016-11-22 22:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-21 19:09 [RFC net-next 0/3] net: bridge: Allow CPU port configuration Florian Fainelli
2016-11-21 19:09 ` [RFC net-next 1/3] net: bridge: Allow bridge master device to configure switch CPU port Florian Fainelli
2016-11-22 15:46 ` Vivien Didelot
2016-11-24 1:49 ` Toshiaki Makita
2016-11-21 19:09 ` [RFC net-next 2/3] net: dsa: Propagate VLAN add/del to CPU port(s) Florian Fainelli
2016-11-22 16:50 ` Vivien Didelot
2016-11-28 4:30 ` Florian Fainelli
2016-11-21 19:09 ` [RFC net-next 3/3] net: dsa: b53: Remove CPU port specific VLAN programming Florian Fainelli
2016-11-22 12:49 ` [RFC net-next 0/3] net: bridge: Allow CPU port configuration Jiri Pirko
2016-11-22 15:29 ` Vivien Didelot
2016-11-22 17:41 ` Ido Schimmel
2016-11-22 17:48 ` Andrew Lunn
2016-11-22 22:08 ` Jiri Pirko [this message]
2016-11-23 0:24 ` Florian Fainelli
2016-11-23 8:21 ` Jiri Pirko
2016-11-22 17:56 ` Florian Fainelli
2016-11-23 13:48 ` Ido Schimmel
2016-12-01 20:21 ` Florian Fainelli
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=20161122220859.GF1819@nanopsycho \
--to=jiri@resnulli.us \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=idosch@idosch.org \
--cc=idosch@mellanox.com \
--cc=jiri@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=vivien.didelot@savoirfairelinux.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).