All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: roopa <roopa@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,
	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 1/9] Introduce devlink infrastructure
Date: Tue, 23 Feb 2016 08:47:01 +0100	[thread overview]
Message-ID: <20160223074701.GB2140@nanopsycho.orion> (raw)
In-Reply-To: <56CB8BB2.3070202@cumulusnetworks.com>

Mon, Feb 22, 2016 at 11:29:06PM CET, roopa@cumulusnetworks.com wrote:
>On 2/22/16, 10:31 AM, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Introduce devlink infrastructure for drivers to register and expose to
>> userspace via generic Netlink interface.
>>
>> There are two basic objects defined:
>> devlink - one instance for every "parent device", for example switch ASIC
>> devlink port - one instance for every physical port of the device.
>
>Like i have expressed earlier, the only thing that bothers me here is that we are creating a new devlink object for switch port when there
>is an existing netdev object.

Sometimes it is, sometimes it is not (IB). I bevelieve that there is a
need for a "handle" for a physical port, regardless what type it is.
The same instance exists all the time, even if you change the type or if
the netdev is not created yet (init phase)


>
>Is there a chance that the drivers you are targeting can still create netdevs for physical ports ?
>It would make things so much more consistent and simpler to manage without a cost of adding yet another interface.

So you see a problem in having devlink_port handle here? It is just an
index, very simple. But you would rather see something like:
myhost:~$ dl dev show
0: devlink0: bus pci dev 0000:01:00.0
myhost:~$ dl port show
ens4: type eth parent devlink0
ens5: type eth parent devlink0
?

There are 2 problems with that approach:
1) It's hard to use this for IB devices, they don't necessary have
   netdev associated.
2) You have to have the netdevs created (know ifindex) in order to work
   with that from userspace. But there are usecases, for example during
   initialization that netdevs are not yet present and user needs to
   specify port for configuration (that is usecase #4 I listed in the cover
   letter)

But it is very easy to change dl userspace tool to be able to use netdev
names to specify ports when possible. Then you could do something like
for example:
myswitch:~$ sudo dl port split eth0 2


>
>The port splitter support is needed at the netdev api too (ie rtnetlink). Most switchdev drivers that expose netdevs
>would benefit from a native 'ip link' way to configure port splitting. This will be useful for nic drivers too.

Why would it be needed in rtnetlink too if it would be exported using
devlink? I don't get it. Sounds similar like if you would expose
wireless-specific stuff via rtnetlink in parallel to nl80211.

  reply	other threads:[~2016-02-23  7:47 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 [this message]
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
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=20160223074701.GB2140@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=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.