From: Arnd Bergmann <arnd@arndb.de>
To: Sunil Kovvuri <sunil.kovvuri@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Linux Netdev List <netdev@vger.kernel.org>,
linux-soc@vger.kernel.org, Sunil Goutham <sgoutham@marvell.com>
Subject: Re: [PATCH v2 00/17] octeontx2-af: NPC parser and NIX blocks initialization
Date: Fri, 26 Oct 2018 16:04:44 +0200 [thread overview]
Message-ID: <CAK8P3a3qL15dmeRYX7W2EC5bGO1qFCXEDRj+xTcGt8Fakwc3vw@mail.gmail.com> (raw)
In-Reply-To: <CA+sq2CdNo4ooSSb3cwZrcbShpWto9uQQB=cfaMAeQqPUdgMv4Q@mail.gmail.com>
On 10/26/18, Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> I see this has been applied, but I'd still like to understand better how
>> the
>> configuration interface is expected to work once the driver is complete.
>>
>> In particular, so far the interfaces all assume that configuration is
>> done through the mailbox between PCI devices, which could be done
>> from a virtual machine kernel with access to PCI, or through the use
>> of VFIO from a user application.
>>
>> Is that the only method of configuring it that you support, or will there
>> also be a devlink based interface or something like that to configure
>> the aspects of a virtual device that should not be accessible to the
>> VF itself?
>>
>
>
> As of now it's only mbox based configuration that is supported.
Ok, thanks for the clarification.
Does this mean that you intend to have user space tools that use
the mbox based interface on VFIO devices to perform configuration
for virtual network devices, or just that the configuration interface
is something that needs to be designed later?
I fear that setting a precedent of using the mbox for user-level
configuration management would mean that we would have to
treat each of these interfaces as an ABI, which in turn requires
much deeper review as well as raising the fundamental question
on how this should be done across drivers. The mailbox interface
seem inherently nonportable to other hardware here, which is
a significant downside.
Arnd
next prev parent reply other threads:[~2018-10-26 22:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-22 17:55 [PATCH v2 00/17] octeontx2-af: NPC parser and NIX blocks initialization sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 01/17] octeontx2-af: NIX Tx scheduler queues alloc/free sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 02/17] octeontx2-af: NIX Tx scheduler queue config support sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 03/17] octeontx2-af: Reset NIXLF's Rx/Tx stats sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 04/17] octeontx2-af: Add NPC KPU profile sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 05/17] octeontx2-af: Config NPC KPU engines with parser profile sunil.kovvuri
2018-10-26 12:07 ` Arnd Bergmann
2018-10-22 17:55 ` [PATCH v2 06/17] octeontx2-af: Config pkind for CGX mapped PFs sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 07/17] octeontx2-af: Broadcast packet replication support sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 08/17] octeontx2-af: Update bcast list upon NIXLF alloc/free sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 09/17] octeontx2-af: Support for VTAG strip and capture sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 10/17] octeontx2-af: Enable packet length and csum validation sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 11/17] octeontx2-af: NPC MCAM and LDATA extract minimal configuration sunil.kovvuri
2018-10-22 17:55 ` [PATCH v2 12/17] octeontx2-af: Add LMAC channel info to NIXLF_ALLOC response sunil.kovvuri
2018-10-22 17:56 ` [PATCH v2 13/17] octeontx2-af: Install ucast and bcast pkt forwarding rules sunil.kovvuri
2018-10-22 17:56 ` [PATCH v2 14/17] octeontx2-af: NIX Rx flowkey configuration for RSS sunil.kovvuri
2018-10-22 17:56 ` [PATCH v2 15/17] octeontx2-af: Support for changing RSS algorithm sunil.kovvuri
2018-10-22 17:56 ` [PATCH v2 16/17] octeontx2-af: Support for setting MAC address sunil.kovvuri
2018-10-22 17:56 ` [PATCH v2 17/17] octeontx2-af: Support for NIXLF's UCAST/PROMISC/ALLMULTI modes sunil.kovvuri
2018-10-23 3:19 ` [PATCH v2 00/17] octeontx2-af: NPC parser and NIX blocks initialization David Miller
2018-10-26 12:54 ` Arnd Bergmann
2018-10-26 13:29 ` Sunil Kovvuri
2018-10-26 14:04 ` Arnd Bergmann [this message]
2018-10-26 15:47 ` Andrew Lunn
2018-10-26 15:55 ` Arnd Bergmann
2018-10-26 16:26 ` Sunil Kovvuri
2018-10-26 16:33 ` Sunil Kovvuri
2018-10-26 19:28 ` Arnd Bergmann
2018-10-29 4:32 ` Sunil Kovvuri
2018-10-29 8:59 ` Arnd Bergmann
2018-10-26 17:16 ` Andrew Lunn
2018-10-26 17:19 ` 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=CAK8P3a3qL15dmeRYX7W2EC5bGO1qFCXEDRj+xTcGt8Fakwc3vw@mail.gmail.com \
--to=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=linux-soc@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sgoutham@marvell.com \
--cc=sunil.kovvuri@gmail.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).