public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu•com>
To: Florian Fainelli <f.fainelli@gmail•com>
Cc: Felix Fietkau <nbd@openwrt•org>,
	Neil Horman <nhorman@tuxdriver•com>,
	John Fastabend <john.r.fastabend@intel•com>,
	netdev <netdev@vger•kernel.org>,
	David Miller <davem@davemloft•net>,
	Sascha Hauer <s.hauer@pengutronix•de>,
	John Crispin <blogic@openwrt•org>,
	Jonas Gorski <jogo@openwrt•org>, Gary Thomas <gary@mlbassoc•com>,
	Vlad Yasevich <vyasevic@redhat•com>,
	Stephen Hemminger <stephen@networkplumber•org>
Subject: Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API
Date: Mon, 28 Oct 2013 18:29:39 -0400	[thread overview]
Message-ID: <526EE553.5050408@mojatatu.com> (raw)
In-Reply-To: <CAGVrzcbmsMjB78_x8MoOf4C34OMMZ-+3RBbheA0bG=r5VUi4EQ@mail.gmail.com>

On 10/27/13 14:14, Florian Fainelli wrote:
> 2013/10/27 Jamal Hadi Salim <jhs@mojatatu•com>:
>> On 10/25/13 09:01, Felix Fietkau wrote:
>>>

>
> They are yes, the only "fancy" features these switches allow is
> basically to set a given's port vlan id, which is already a huge
> improvement compared to the vendor provided firmware.
>

Nice to know that you have something better than the vendor provided
stuff.

>
> The switch does have an address learning process which is usually not
> controlled by software at all, so yes, flooding is usually the way to
> get it to the CPU.
>

Ok.

> Which exact drivers are you refering to? If we are talking about DSA
> then yes, this is correct, but it is completely Ethernet MAC driver
> agnostic.
>

Sorry - cant point you to an exact one; one that i tried to convert to
NAPI and found these issues was from Netlogic (embedded 64 bit mips),
that i think now is in the kernel proper (and someone had converted to
NAPI as well). Let me get back to you with some sample examples..

> Why would we expose the hardware switch physical ports as netdevs if
> we cannot even any control over their data-path? Unlike these
> multiport NICs, the only traffic you see and you can control is the
> one from your CPU port.
>

Not necessarily for datapath, rather for control path. If i can
pull the stats, ifconfig up/down the port, set flow control
etc - then that is a  good reason to expose them.

>
> I do not really see how we could bend the existing interface (is it
> rtnetlink we are talking about or something else btw?) to expose these
> switches, maybe we could with iproute2, but still, the user-space
> interface/tool is far from being the problem here.
>

Look at the FDB API.
The user space interface as well as reusing kernel interfaces is my main
arguement.

> I don't think at any point in this discussion there was a mention that
> we do not want to change the user or kernel interface in OpenWrt
> because we have been using this for the past 5 years, on the contrary,
> if we are bringing this to a wide audience, this is to get some proper
> review and eventually change it.
>

Ok, sorry - I misinterpreted you and Felix. Like i said, if you gave me
that reason I would understand.

cheers,
jamal

  reply	other threads:[~2013-10-28 22:29 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-22 18:23 [PATCH 0/4 net-next] net: phy: add Generic Netlink switch configuration API Florian Fainelli
2013-10-22 18:23 ` [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet " Florian Fainelli
2013-10-22 19:22   ` Dan Williams
2013-10-22 19:32     ` Florian Fainelli
2013-10-22 19:47       ` David Miller
     [not found]         ` <1382477150.19269.69.camel@dcbw.foobar.com>
2013-10-22 21:22           ` David Miller
2013-10-22 19:46     ` David Miller
2013-10-22 19:53   ` John Fastabend
2013-10-22 19:59     ` Florian Fainelli
2013-10-22 20:25       ` Neil Horman
2013-10-22 22:09         ` Florian Fainelli
2013-10-23 11:34           ` Neil Horman
2013-10-23 11:47           ` Jamal Hadi Salim
2013-10-23 12:04             ` Felix Fietkau
2013-10-23 12:53               ` Jamal Hadi Salim
2013-10-23 13:31                 ` Felix Fietkau
2013-10-23 14:09                   ` Jamal Hadi Salim
2013-10-23 14:32                     ` Felix Fietkau
2013-10-25 11:43                       ` Jamal Hadi Salim
2013-10-25 13:01                         ` Felix Fietkau
2013-10-27 17:19                           ` Jamal Hadi Salim
2013-10-27 18:14                             ` Florian Fainelli
2013-10-28 22:29                               ` Jamal Hadi Salim [this message]
2013-10-27 19:51                             ` Felix Fietkau
2013-10-28 22:53                               ` Jamal Hadi Salim
2013-10-29  9:34                                 ` Felix Fietkau
2013-10-30 11:45                                   ` Jamal Hadi Salim
2013-10-30 12:53                                     ` Felix Fietkau
2013-10-30 17:27                                 ` Lennert Buytenhek
2013-10-30 17:34                                   ` Lennert Buytenhek
2013-10-30 17:56                                     ` John Fastabend
2013-10-30 17:56                                     ` John Fastabend
2013-10-30 19:47                                   ` Felix Fietkau
2013-12-07  1:45                                     ` Florian Fainelli
2013-10-29 23:12                 ` Maxime Bizon
2013-10-30 11:50                   ` Jamal Hadi Salim
2013-10-30 11:58                     ` Felix Fietkau
2013-10-30 14:28                     ` Maxime Bizon
2013-10-22 18:23 ` [PATCH 2/4 net-next] tools: add Generic Netlink switch configuration tool Florian Fainelli
2013-10-22 18:23 ` [PATCH 3/4 net-next] net: phy: add Broadcom B53 switch driver Florian Fainelli
2013-10-22 18:23 ` [PATCH 4/4 net-next] net: phy: add fake " 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=526EE553.5050408@mojatatu.com \
    --to=jhs@mojatatu$(echo .)com \
    --cc=blogic@openwrt$(echo .)org \
    --cc=davem@davemloft$(echo .)net \
    --cc=f.fainelli@gmail$(echo .)com \
    --cc=gary@mlbassoc$(echo .)com \
    --cc=jogo@openwrt$(echo .)org \
    --cc=john.r.fastabend@intel$(echo .)com \
    --cc=nbd@openwrt$(echo .)org \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=nhorman@tuxdriver$(echo .)com \
    --cc=s.hauer@pengutronix$(echo .)de \
    --cc=stephen@networkplumber$(echo .)org \
    --cc=vyasevic@redhat$(echo .)com \
    /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