From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Cc: Jiri Pirko <jiri@resnulli.us>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Michal Kalderon <mkalderon@marvell.com>,
"Ariel Elior" <aelior@marvell.com>
Subject: Re: [EXT] Re: [PATCH net-next 4/4] qed: Add devlink support for configuration attributes.
Date: Wed, 3 Jul 2019 10:42:44 -0700 [thread overview]
Message-ID: <20190703104244.7d26e734@cakuba.netronome.com> (raw)
In-Reply-To: <MN2PR18MB2528065BE3D46045F7EA1888D3FB0@MN2PR18MB2528.namprd18.prod.outlook.com>
On Wed, 3 Jul 2019 12:56:39 +0000, Sudarsana Reddy Kalluru wrote:
> Apologies for bringing this topic again. From the driver(s) code
> paths/'devlink man pages', I understood that devlink-port object is
> an entity on top of the PCI bus device. Some drivers say NFP
> represents vnics (on pci-dev) as a devlink-ports and, some represents
> (virtual?) ports on the PF/device as devlink-ports. In the case of
> Marvell NIC driver, we don't have [port] partitioning of the PCI
> device. And the config attributes are specific to PCI-device (not the
> vports/vnics of PF). Hence I didn't see a need for creating
> devlink-port objects in the system for Marvell NICs. And planning to
> add the config attributes to 'devlink-dev' object. Please let me know
> if my understanding and the proposal is ok?
I understand where you're coming from.
We want to make that judgement call on attribute-by-attribute basis.
We want consistency across vendors (and, frankly, multiple drivers of
the same vendor). If attribute looks like it belongs to the port,
rather than the entire device/ASIC operation, we should make it a port
attribute.
next prev parent reply other threads:[~2019-07-03 17:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 11:45 [PATCH net-next 0/4] qed: Devlink support for config attributes management Sudarsana Reddy Kalluru
2019-06-17 11:45 ` [PATCH net-next 1/4] qed: Add APIs for device attributes configuration Sudarsana Reddy Kalluru
2019-06-17 11:45 ` [PATCH net-next 2/4] qed: Perform devlink registration after the hardware init Sudarsana Reddy Kalluru
2019-06-17 11:45 ` [PATCH net-next 3/4] qed: Add new file for devlink implementation Sudarsana Reddy Kalluru
2019-06-17 11:45 ` [PATCH net-next 4/4] qed: Add devlink support for configuration attributes Sudarsana Reddy Kalluru
2019-06-17 22:54 ` Jakub Kicinski
2019-06-20 12:09 ` [EXT] " Sudarsana Reddy Kalluru
2019-06-20 13:37 ` Jiri Pirko
2019-06-26 6:46 ` Sudarsana Reddy Kalluru
2019-07-03 12:56 ` Sudarsana Reddy Kalluru
2019-07-03 17:42 ` Jakub Kicinski [this message]
2019-07-04 5:49 ` Sudarsana Reddy Kalluru
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=20190703104244.7d26e734@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=aelior@marvell.com \
--cc=davem@davemloft.net \
--cc=jiri@resnulli.us \
--cc=mkalderon@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=skalluru@marvell.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.