netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Shannon Nelson <snelson@pensando.io>
Cc: netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH v3 net-next 7/8] ionic: add support for device id 0x1004
Date: Thu, 5 Mar 2020 17:18:34 -0800	[thread overview]
Message-ID: <20200305171834.6c52b5e9@kicinski-fedora-PC1C0HJN> (raw)
In-Reply-To: <d9df0828-91d6-9089-e1b4-d82c6479d44c@pensando.io>

On Thu, 5 Mar 2020 16:41:48 -0800 Shannon Nelson wrote:
> On 3/5/20 2:03 PM, Jakub Kicinski wrote:
> > On Wed,  4 Mar 2020 21:23:18 -0800 Shannon Nelson wrote:  
> >> Add support for an additional device id.
> >>
> >> Signed-off-by: Shannon Nelson <snelson@pensando.io>  
> > I have thought about this for a while and I wanted to ask you to say
> > a bit more about the use of the management device.
> >
> > Obviously this is not just "additional device id" in the traditional
> > sense where device IDs differentiate HW SKUs or revisions. This is the
> > same exact hardware, just a different local feature (as proven by the
> > fact that you make 0 functional changes).
> >
> > In the past we (I?) rejected such extensions upstream from Netronome and
> > Cavium, because there were no clear use cases which can't be solved by
> > extending standard kernel APIs. Do you have any?  
> 
> Do you by chance have any references handy to such past discussions?  
> I'd be interested in reading them to see what similarities and 
> differences we have.

Here you go:

https://lore.kernel.org/netdev/20170718115827.7bd737f2@cakuba.netronome.com/

> The network device we present is only a portion of the DSC's functions.  
> The device configuration and management for the various services is 
> handled in userspace programs on the OS running inside the device.  
> These are accessed through a secured REST API, typically through the 
> external management ethernet port.  In addition to our centralized 
> management user interface, we have a command line tool for managing the 
> device configuration using that same REST interface.

We try to encourage vendors to create common interfaces, as you'd
understand that command line tool is raising red flags.

Admittedly most vendors have some form of command line tool which can
poke directly into registers, anyway, but IMHO we should avoid any
precedents of merging driver patches with explicit goal of enabling
such tools.

> In some configurations we make it possible to open a network connection 
> into the device through the host PCI, just as if you were to connect 
> through the external mgmt port.  This is the PCI deviceid that 
> corresponds to that port, and allows use of the command line tool on the 
> host.
> 
> The host network driver doesn't have access to the device management 
> commands, it only can configure the NIC portion for what it needs for 
> passing network packets.


  reply	other threads:[~2020-03-06  1:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05  5:23 [PATCH v3 net-next 0/8] ionic updates Shannon Nelson
2020-03-05  5:23 ` [PATCH v3 net-next 1/8] ionic: keep ionic dev on lif init fail Shannon Nelson
2020-03-05  5:23 ` [PATCH v3 net-next 2/8] ionic: remove pragma packed Shannon Nelson
2020-03-05  5:23 ` [PATCH v3 net-next 3/8] ionic: improve irq numa locality Shannon Nelson
2020-03-05  5:23 ` [PATCH v3 net-next 4/8] ionic: clean up bitflag usage Shannon Nelson
2020-03-05  5:23 ` [PATCH v3 net-next 5/8] ionic: support ethtool rxhash disable Shannon Nelson
2020-03-05  5:23 ` [PATCH v3 net-next 6/8] ionic: print pci bus lane info Shannon Nelson
2020-03-05  5:23 ` [PATCH v3 net-next 7/8] ionic: add support for device id 0x1004 Shannon Nelson
2020-03-05 22:03   ` Jakub Kicinski
2020-03-06  0:41     ` Shannon Nelson
2020-03-06  1:18       ` Jakub Kicinski [this message]
2020-03-06  7:43         ` Shannon Nelson
2020-03-06 18:20           ` Jakub Kicinski
2020-03-06 20:32             ` Shannon Nelson
2020-03-06 21:28               ` Jakub Kicinski
2020-03-06 22:57                 ` Shannon Nelson
2020-03-05  5:23 ` [PATCH v3 net-next 8/8] ionic: drop ethtool driver version Shannon Nelson
2020-03-05  6:10   ` Leon Romanovsky
2020-03-05  7:20     ` Shannon Nelson
2020-03-05  7:52       ` Leon Romanovsky

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=20200305171834.6c52b5e9@kicinski-fedora-PC1C0HJN \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=snelson@pensando.io \
    /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).