All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Andy Gospodarek <gospo@cumulusnetworks.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, idosch@mellanox.com,
	eladr@mellanox.com, yotamg@mellanox.com, ogerlitz@mellanox.com,
	yishaih@mellanox.com, dledford@redhat.com, sean.hefty@intel.com,
	hal.rosenstock@gmail.com, eugenia@mellanox.com,
	roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com,
	hadarh@mellanox.com, jhs@mojatatu.com, john.fastabend@gmail.com,
	jeffrey.t.kirsher@intel.com, brouer@redhat.com,
	ivecera@redhat.com, rami.rosen@intel.com
Subject: Re: [patch net-next 0/9] Introduce devlink interface and first drivers to use it
Date: Tue, 23 Feb 2016 08:32:03 +0100	[thread overview]
Message-ID: <20160223073203.GA2140@nanopsycho.orion> (raw)
In-Reply-To: <20160223051214.GP33942@gospo.home.greyhouse.net>

Tue, Feb 23, 2016 at 06:12:15AM CET, gospo@cumulusnetworks.com wrote:
>On Mon, Feb 22, 2016 at 07:31:55PM +0100, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>> 
>> There a is need for some userspace API that would allow to expose things
>> that are not directly related to any device class like net_device of
>> ib_device, but rather chip-wide/switch-ASIC-wide stuff.
>> 
>> Use cases:
>> 1) get/set of port type (Ethernet/InfiniBand)
>> 2) setting up port splitters - split port into multiple ones and squash again,
>>    enables usage of splitter cable
>> 3) setting up shared buffers - shared among multiple ports within
>>    one chip (work in progress)
>> 4) configuration of switch wide properties - resources division etc - This will
>>    allow to pass configuration that is unacceptable to be passed as
>>    a module option.
>
>I'm generally a fan of use cases #3 and #4 (as we have previously
>discussed), but I'm not sure I agree that the implementation for #2
>right now.
>
>I'm not sure I would like userspace to have control over whether or not
>a port should be split or not when the hardware can be queried to
>determine this.

I was thinking about this myself for a long time and initially it made
more sense to me the approach you are suggesting. But after lot of
thining, I saw a lot of issues, I changed my mind and now I believe that
splitter should be set by user.

when you set the splitter port, you have 2 or 4 ports created in
hardware. They looks exactly the same as unsplitted ports, they are only
wired up differently. There is a netdev created for every splitter port,
user would add it to bridge, bond, vlan, set routes, define static fdb
entry and hw would learn fdbs itself. Now when someone disconnects the
splitter cable, 2 things may happen:
1) yourway. Netdevs disappear, all configs and state info will disappear
   with it.
2) myway. Netdevs stay, only link is down. This is the same behaviour is
   if someone uplugs cable for unplitted port.

There are also similar issues before you plug the splitter cable. So it
makes sense to let user co configure this. He knows what he wants. 1)
does not look like correct behaviour to me, 2) does.



<snip>

>> 	myhost:~$ dl port show
>> 	devlink0/1: type eth netdev ens4
>                             ^^^^^^^^^^^
>> 	devlink0/2: type ib ibdev mlx4_0
>                            ^^^^^^^^^^^^
>I think my only other question about this implementation is whether or
>not one would really want to have the true netdev/ibdev names mapped
>here.
>
>Would be as reasonable to simply specify the type (and there may be more
>types within ethernet that could be useful in multi-chip configurations)
>and then let normal infrastructure that exists today figure out how to
>map the names for the netdevs to the devices?

What normal infrastructure you have in mind? There is no info about
devlink port mapping to netdev/ibdev anywhere. Only here. I might be
missing something but I fail to see what's wrong with it.

  reply	other threads:[~2016-02-23  7:32 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-22 18:31 [patch net-next 0/9] Introduce devlink interface and first drivers to use it Jiri Pirko
2016-02-22 18:31 ` [patch net-next 1/9] Introduce devlink infrastructure Jiri Pirko
2016-02-22 22:29   ` roopa
2016-02-23  7:47     ` Jiri Pirko
2016-02-24  7:02   ` Yuval Mintz
2016-02-24 10:56     ` Jiri Pirko
2016-02-22 18:31 ` [patch net-next 2/9] mlx4: Implement devlink interface Jiri Pirko
2016-02-22 18:31 ` [patch net-next 3/9] mlx4: Implement port type setting via " Jiri Pirko
2016-02-23 11:26   ` Hannes Frederic Sowa
2016-02-23 12:21     ` Jiri Pirko
2016-02-23 13:28       ` Hannes Frederic Sowa
2016-02-23 14:26         ` Jiri Pirko
2016-02-23 15:16           ` Hannes Frederic Sowa
2016-02-23 15:30             ` Jiri Pirko
2016-02-23 15:57               ` Hannes Frederic Sowa
2016-02-23 16:04                 ` Jiri Pirko
2016-02-23 16:45                   ` Hannes Frederic Sowa
2016-02-23 16:55                     ` Jiri Pirko
2016-02-23 17:07                       ` Hannes Frederic Sowa
2016-02-23 15:20           ` Andy Gospodarek
2016-02-23 15:31             ` Jiri Pirko
2016-02-23 18:16       ` David Miller
2016-02-23 17:31     ` Stephen Hemminger
2016-02-24  7:15       ` Jiri Pirko
2016-02-22 18:31 ` [patch net-next 4/9] mlxsw: Implement " Jiri Pirko
2016-02-22 18:32 ` [patch net-next 5/9] mlxsw: core: Add devlink port splitter callbacks Jiri Pirko
2016-02-22 18:32 ` [patch net-next 6/9] mlxsw: spectrum: Unmap local port from module during teardown Jiri Pirko
2016-02-22 20:32   ` John Fastabend
2016-02-22 21:00     ` Ido Schimmel
2016-02-22 21:08       ` John Fastabend
2016-02-23  4:50     ` Andy Gospodarek
2016-02-22 18:32 ` [patch net-next 7/9] mlxsw: spectrum: Store local port to module mapping during init Jiri Pirko
2016-02-22 18:32 ` [patch net-next 8/9] mlxsw: spectrum: Mark unused ports using NULL Jiri Pirko
2016-02-22 18:32 ` [patch net-next 9/9] mlxsw: spectrum: Introduce port splitting Jiri Pirko
2016-02-23  5:12 ` [patch net-next 0/9] Introduce devlink interface and first drivers to use it Andy Gospodarek
2016-02-23  7:32   ` Jiri Pirko [this message]
2016-02-23 14:34     ` Andy Gospodarek
2016-02-23 14:45       ` Jiri Pirko
2016-02-23 15:55         ` Andy Gospodarek
2016-02-23 16:01           ` Jiri Pirko
2016-02-23 16:19             ` Andy Gospodarek
2016-02-23 16:23               ` Jiri Pirko

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=20160223073203.GA2140@nanopsycho.orion \
    --to=jiri@resnulli.us \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dledford@redhat.com \
    --cc=eladr@mellanox.com \
    --cc=eugenia@mellanox.com \
    --cc=gospo@cumulusnetworks.com \
    --cc=hadarh@mellanox.com \
    --cc=hal.rosenstock@gmail.com \
    --cc=idosch@mellanox.com \
    --cc=ivecera@redhat.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jhs@mojatatu.com \
    --cc=john.fastabend@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@cumulusnetworks.com \
    --cc=ogerlitz@mellanox.com \
    --cc=rami.rosen@intel.com \
    --cc=roopa@cumulusnetworks.com \
    --cc=sean.hefty@intel.com \
    --cc=yishaih@mellanox.com \
    --cc=yotamg@mellanox.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.