All of lore.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.com \
    --cc=blogic@openwrt.org \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=gary@mlbassoc.com \
    --cc=jogo@openwrt.org \
    --cc=john.r.fastabend@intel.com \
    --cc=nbd@openwrt.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=s.hauer@pengutronix.de \
    --cc=stephen@networkplumber.org \
    --cc=vyasevic@redhat.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 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.