From: Jiri Pirko <jiri@resnulli.us>
To: "Mintz, Yuval" <Yuval.Mintz@cavium.com>
Cc: Jakub Kicinski <kubakici@wp.pl>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"oss-drivers@netronome.com" <oss-drivers@netronome.com>
Subject: Re: [PATCH net-next 00/16] nfp: ctrl vNIC
Date: Tue, 6 Jun 2017 13:20:43 +0200 [thread overview]
Message-ID: <20170606112043.GD1911@nanopsycho> (raw)
In-Reply-To: <BLUPR0701MB2004F8E6F28C1181003BEA788DCB0@BLUPR0701MB2004.namprd07.prod.outlook.com>
Tue, Jun 06, 2017 at 11:35:08AM CEST, Yuval.Mintz@cavium.com wrote:
>
>> >> >What were your plans with pre-netdev config?
>> >>
>> >> We need to pass come initial resource division. Generally the
>> >> consensus is to have these options exposed through devlink, let the
>> >> user configure them all and then to have a trigger that would cause
>> >> driver re-orchestration according to the new values. The flow would
>> >> look like
>> >> this:
>> >>
>> >> -driver loads with defaults, inits hw and instantiates netdevs
>> >> -driver exposes config options via devlink -user sets up the options
>> >> -user pushes the "go" trigger -upon the trigger command, devlink
>> >> calls the driver re-init callback -driver shuts down the current
>> >> instances, re-initializes hw, re-instantiates the netdevs
>> >>
>> >> Makes sense?
>> >
>> >I like the idea of a "go"/apply/reload trigger and extending devlink.
>> >Do you plan on adding a way to persist the settings? I'm concerned NIC
>> >users may want to boot into the right mode once it's set, without
>> >reloads and reconfigs upon boot. Also is there going to be a way to
>> >query the pending/running config? Sounds like we may want to expose
>> >three value sets - persistent/default, running and pending/to be
>> >applied.
>
>> I don't think it is a good idea to introduce any kind of configuration
>> persistency in HW. I believe that user is the master and he has all needed
>> info. He can store it persistently, but it is up to him.
>>
>> So basicaly during boot, we need the devlink configuration to happen early
>> on, before the netdevices get configured. udev? Not sure how exactly to do
>> this. Have to ask around :)
>
>Thinking about use cases where we'd want information available at probe time,
>it might have been even better to have it separated from the netdevice,
>e.g., providing clients with node to configure (generic?) information on top of
>their PCI nodes.
Yuval, devlink is separated from the netdevices....
next prev parent reply other threads:[~2017-06-06 11:20 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 0:01 [PATCH net-next 00/16] nfp: ctrl vNIC Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 01/16] nfp: reorder open and close functions Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 02/16] nfp: split out the allocation part of open Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 03/16] nfp: reuse ring free code on close Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 04/16] nfp: move nfp_net_vecs_init() Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 05/16] nfp: prepare print macros for use without netdev Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 06/16] nfp: make sure debug accesses don't depend on netdevs Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 07/16] nfp: allow allocation and initialization of netdev-less vNICs Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 08/16] nfp: prepare config and enable for working without netdevs Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 09/16] nfp: add control vNIC datapath Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 10/16] nfp: make vNIC ctrl memory mapping function reusable Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 11/16] nfp: map all queue controllers at once Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 12/16] nfp: don't clutter init code passing fw_ver around Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 13/16] nfp: slice the netdev spawning function Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 14/16] nfp: allow non-equal distribution of IRQs Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 15/16] nfp: create control vNICs and wire up rx/tx Jakub Kicinski
2017-06-06 0:01 ` [PATCH net-next 16/16] nfp: advertise support for NFD ABI 0.5 Jakub Kicinski
2017-06-06 6:16 ` [PATCH net-next 00/16] nfp: ctrl vNIC Jiri Pirko
2017-06-06 7:21 ` Jakub Kicinski
2017-06-06 8:23 ` Jiri Pirko
2017-06-06 9:09 ` Jakub Kicinski
2017-06-06 9:17 ` Jiri Pirko
2017-06-06 9:35 ` Mintz, Yuval
2017-06-06 11:20 ` Jiri Pirko [this message]
2017-06-07 17:48 ` Mintz, Yuval
2017-06-08 5:38 ` Jiri Pirko
2017-06-08 6:33 ` Mintz, Yuval
2017-06-08 6:38 ` Jiri Pirko
2017-06-06 19:54 ` Jakub Kicinski
2017-06-07 16:52 ` David Miller
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=20170606112043.GD1911@nanopsycho \
--to=jiri@resnulli.us \
--cc=Yuval.Mintz@cavium.com \
--cc=kubakici@wp.pl \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.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 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).