[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180417161915.193c3651@cakuba.netronome.com>
Date: Tue, 17 Apr 2018 16:19:15 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Andy Gospodarek <andrew.gospodarek@...adcom.com>
Cc: Or Gerlitz <gerlitz.or@...il.com>,
"Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
David Miller <davem@...emloft.net>,
Anjali Singhai Jain <anjali.singhai@...el.com>,
Michael Chan <michael.chan@...adcom.com>,
Simon Horman <simon.horman@...ronome.com>,
John Fastabend <john.fastabend@...il.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Jiri Pirko <jiri@...lanox.com>,
Rony Efraim <ronye@...lanox.com>,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: SRIOV switchdev mode BoF minutes
On Tue, 17 Apr 2018 10:47:00 -0400, Andy Gospodarek wrote:
> There is also a school of thought that the VF reps could be
> pre-allocated on the SmartNIC so that any application processing that
> traffic would sit idle when no traffic arrives on the rep, but could
> process frames that do arrive when the VFs were created on the host.
> This implementation will depend on how resources are allocated on a
> given bit of hardware, but can really work well.
+1 if there is no FW resource allocation issues IMHO it's okay to
just show all reprs for "remote PCIes (PFs and VFs)" on the SmartNIC/
controller. The reprs should just show link down as if PCIe cable
was unpluged until host actually enables them.
A similar issue exists on multi-host for PFs, right? If one of the
hosts is down do we still show their PF repr? IMHO yes.
That makes the thing looks more like a switch with cables being plugged
in and out.
Powered by blists - more mailing lists