[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKOOJTz_rWCss1eEHPnDE-1_x0QefLS3NKwyPVsg_GBNxw+daw@mail.gmail.com>
Date: Mon, 18 Jan 2021 21:06:30 -0800
From: Edwin Peer <edwin.peer@...adcom.com>
To: David Ahern <dsahern@...il.com>
Cc: Jiri Pirko <jiri@...nulli.us>, netdev <netdev@...r.kernel.org>,
"David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Jacob Keller <jacob.e.keller@...el.com>, roopa@...dia.com,
mlxsw <mlxsw@...dia.com>
Subject: Re: [patch net-next RFC 00/10] introduce line card support for
modular switch
On Mon, Jan 18, 2021 at 6:39 PM David Ahern <dsahern@...il.com> wrote:
> > Indeed, this is what we ended up doing, although we still need to
> > confirm Network Manager, systemd and whatever else our customers might
> > use do the necessary to satisfy the user requirement to handle the
> > delayed init.
>
> I am not surprised about the issue - boot times have been improved and
> devices have gotten more complicated. And I was wondering how network
> managers (add ifupdown{2} to that list) would handle an EAGAIN. You
> could have an event sent -- e.g., IFLA_EVENT_FW_READY -- to allow
> managers to avoid polling. Redundant for multiple netdev's per device,
> but makes it event driven.
This is what I was hinting at by talking about another device state.
For that, there would necessarily need to be an event to inform user
space about the transition out of said state into normal open/up. Of
course, the tools would need to be updated to know about such a new
event too. EAGAIN does seem simpler. In our case, we don't expect to
be polling too long, or frequently for that matter. It is
exceptionally rare that the firmware wouldn't be ready, but it can
happen.
Regards,
Edwin Peer
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4160 bytes)
Powered by blists - more mailing lists