archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <>
To: Leon Romanovsky <>
Cc: "David S . Miller" <>,,
Subject: Re: [PATCH net-next v1] netdevsim: Forbid devlink reload when adding or deleting ports
Date: Thu, 5 Aug 2021 12:12:03 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YQwnr/qel0oktItP@unreal>

On Thu, 5 Aug 2021 21:02:23 +0300 Leon Romanovsky wrote:
> > > As it should, given add/delete ports takes the port_list_lock which is
> > > destroyed by down but not (due to the forced failure) re-initialized by
> > > up.
> > > 
> > > If we want to handle adding ports while down we can just bump port
> > > count and return, although I don't think there's a practical need
> > > to support that.  
> > 
> > Sorry, but for me netdevsim looks like complete dumpster. 

I worry that netdevsim's gone unwieldy as a reflection of the quality of
the devlink APIs that got added, not by itself :/

> > It was intended for fast prototyping, but ended to be huge pile of
> > debugfs entries and selftest to execute random flows.

It's for selftests, IDK what fast prototyping is in terms of driver
APIs. Fast prototyping makes me think of the "it works" attitude which
is not sufficiently high bar for core APIs IMO, I'm sure you'll agree.

netdevsim was written specifically to be able to exercise HW APIs which
are implemented by small fraction of drivers. Especially offload APIs
as those can easily be broken by people changing the SW implementation
without capable HW at hand.

BTW I wonder if there is a term in human science of situation like when
a recent contributor tells the guy who wrote the code what the code was
intended for :)

> > Do you want me to move in_reload = false line to be after if (nsim_dev->fail_reload)
> > check?  
> BTW, the current implementation where in_reload before if, actually
> preserves same behaviour as was with devlink_reload_enable() implementation.

Right, but I think as you rightly pointed out the current protection
of reload is broken. I'm not saying you must make it perfect or else..
just pointing out a gap you could address if you so choose.

  reply	other threads:[~2021-08-05 19:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 11:02 [PATCH net-next] netdevsim: Forbid devlink reload when adding or deleting ports Leon Romanovsky
2021-08-05 11:05 ` [PATCH net-next v1] " Leon Romanovsky
2021-08-05 12:40 ` [PATCH net-next] " patchwork-bot+netdevbpf
2021-08-05 13:15 ` [PATCH net-next v1] " Jakub Kicinski
2021-08-05 13:51   ` Leon Romanovsky
2021-08-05 14:23     ` Jakub Kicinski
2021-08-05 14:33       ` Leon Romanovsky
2021-08-05 15:27         ` Jakub Kicinski
2021-08-05 17:35           ` Leon Romanovsky
2021-08-05 18:02             ` Leon Romanovsky
2021-08-05 19:12               ` Jakub Kicinski [this message]
2021-08-06 11:19                 ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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).