From: "Keller, Jacob E" <jacob.e.keller@intel.com>
To: "Keller, Jacob E" <jacob.e.keller@intel.com>,
Jakub Kicinski <kuba@kernel.org>
Cc: Jiri Pirko <jiri@resnulli.us>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: RE: [net-next PATCH 1/2] devlink: add dry run attribute to flash update
Date: Mon, 25 Jul 2022 20:33:09 +0000 [thread overview]
Message-ID: <SA2PR11MB510075C54D0A3A1087307E89D6959@SA2PR11MB5100.namprd11.prod.outlook.com> (raw)
In-Reply-To: <SA2PR11MB5100005E9FEB757A6364C2CFD6959@SA2PR11MB5100.namprd11.prod.outlook.com>
> -----Original Message-----
> From: Keller, Jacob E <jacob.e.keller@intel.com>
> Sent: Monday, July 25, 2022 1:27 PM
> To: Jakub Kicinski <kuba@kernel.org>
> Cc: Jiri Pirko <jiri@resnulli.us>; netdev@vger.kernel.org
> Subject: RE: [net-next PATCH 1/2] devlink: add dry run attribute to flash update
>
>
>
> > -----Original Message-----
> > From: Jakub Kicinski <kuba@kernel.org>
> > Sent: Monday, July 25, 2022 12:39 PM
> > To: Keller, Jacob E <jacob.e.keller@intel.com>
> > Cc: Jiri Pirko <jiri@resnulli.us>; netdev@vger.kernel.org
> > Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash update
> >
> > On Mon, 25 Jul 2022 19:15:10 +0000 Keller, Jacob E wrote:
> > > I'm not sure exactly what the process would be here. Maybe something
> > > like:
> > >
> > > 1. identify all of the commands which aren't yet strict
> > > 2. introduce new command IDs for these commands with something like
> > > _STRICT as a suffix? (or something shorter like _2?) 3. make all of
> > > those commands strict validation..
> > >
> > > but now that I think about that, i am not sure it would work. We use
> > > the same attribute list for all devlink commands. This means that
> > > strict validation would only check that its passed existing/known
> > > attributes? But that doesn't necessarily mean the kernel will process
> > > that particular attribute for a given command does it?
> > >
> > > Like, once we introduce DEVLINK_ATTR_DRY_RUN support for flash, if we
> > > then want to introduce it later to something like port splitting.. it
> > > would be a valid attribute to send from kernels which support flash
> > > but would still be ignored on kernels that don't yet support it for
> > > port splitting?
> > >
> > > Wouldn't we want each individual command to have its own validation
> > > of what attributes are valid?
> > >
> > > I do think its probably a good idea to migrate to strict mode, but I
> > > am not sure it solves the problem of dry run. Thoughts? Am I missing
> > > something obvious?
> > >
> > > Would we instead have to convert from genl_small_ops to genl_ops and
> > > introduce a policy for each command? I think that sounds like the
> > > proper approach here....
> >
> > ...or repost without the comment and move on. IDK if Jiri would like
> > to see the general problem of attr rejection solved right now but IMHO
> > it's perfectly fine to just make the user space DTRT.
>
> Its probably worth fixing policy, but would like to come up with a proper path
> that doesn't break compatibility and that will require discussion to figure out
> what approach works.
>
> I'll remove the comment though since this problem affects all attributes.
>
> Thanks,
> Jake
Hmm. The more I think about it, the more it seems that per-command policy is the only way to make the addition of dry_run to new commands safe. Without it, we'd run the risk of a future kernel supporting dry_run but a command not supporting it yet.
next prev parent reply other threads:[~2022-07-25 20:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 18:34 [net-next PATCH 0/2] devlink: implement dry run support for flash update Jacob Keller
2022-07-20 18:34 ` [net-next PATCH 1/2] devlink: add dry run attribute to " Jacob Keller
2022-07-21 5:54 ` Jiri Pirko
2022-07-21 20:32 ` Keller, Jacob E
2022-07-22 6:18 ` Jiri Pirko
2022-07-22 21:12 ` Keller, Jacob E
2022-07-23 15:42 ` Jiri Pirko
2022-07-25 19:15 ` Keller, Jacob E
2022-07-25 19:39 ` Jakub Kicinski
2022-07-25 20:27 ` Keller, Jacob E
2022-07-25 20:32 ` Jakub Kicinski
2022-07-25 20:46 ` Keller, Jacob E
2022-07-26 1:13 ` Jakub Kicinski
2022-07-26 17:23 ` Keller, Jacob E
2022-07-26 18:48 ` Jakub Kicinski
2022-07-26 18:49 ` Keller, Jacob E
2022-07-26 18:21 ` Keller, Jacob E
2022-08-05 16:32 ` Keller, Jacob E
2022-08-05 18:51 ` Jakub Kicinski
2022-08-05 19:50 ` Keller, Jacob E
2022-07-25 20:33 ` Keller, Jacob E [this message]
2022-07-21 16:47 ` Jakub Kicinski
2022-07-21 18:57 ` Keller, Jacob E
2022-07-21 16:48 ` Jakub Kicinski
2022-07-21 18:57 ` Keller, Jacob E
2022-07-20 18:34 ` [net-next PATCH 2/2] ice: support dry run of a flash update to validate firmware file Jacob Keller
2022-07-21 5:56 ` Jiri Pirko
2022-07-21 18:57 ` Keller, Jacob E
2022-07-21 7:53 ` Leon Romanovsky
2022-07-21 5:57 ` [net-next PATCH 0/2] devlink: implement dry run support for flash update 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=SA2PR11MB510075C54D0A3A1087307E89D6959@SA2PR11MB5100.namprd11.prod.outlook.com \
--to=jacob.e.keller@intel.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/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).