netdev - RE: [EXTERNAL] [PATCH net-next] docs: net: document guidance of implementing the SR-IOV NDOs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 19 Jun 2024 16:37:02 +0000
From: Sunil Kovvuri Goutham <sgoutham@...vell.com>
To: Jakub Kicinski <kuba@...nel.org>,
        "davem@...emloft.net"
	<davem@...emloft.net>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "edumazet@...gle.com"
	<edumazet@...gle.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "netdev-driver-reviewers@...r.kernel.org"
	<netdev-driver-reviewers@...r.kernel.org>,
        "corbet@....net" <corbet@....net>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: RE: [EXTERNAL] [PATCH net-next] docs: net: document guidance of
 implementing the SR-IOV NDOs



>-----Original Message-----
>From: Jakub Kicinski <kuba@...nel.org>
>Sent: Wednesday, June 19, 2024 12:58 AM
>To: davem@...emloft.net
>Cc: netdev@...r.kernel.org; edumazet@...gle.com; pabeni@...hat.com; netdev-
>driver-reviewers@...r.kernel.org; Jakub Kicinski <kuba@...nel.org>;
>corbet@....net; linux-doc@...r.kernel.org
>Subject: [PATCH net-next] docs: net: document guidance of
>implementing the SR-IOV NDOs
>
>New drivers were prevented from adding ndo_set_vf_* callbacks over the last few
>years. This was expected to result in broader switchdev adoption, but seems to
>have had little effect. Based on recent netdev meeting there is broad support for
>allowing adding those ops.
>
>There is a problem with the current API supporting a limited number of VFs (100+,
>which is less than some modern HW supports).
>We can try to solve it by adding similar functionality on devlink ports, but that'd be
>another API variation to maintain.
>So a netlink attribute reshuffling is a more likely outcome.
>
>Document the guidance, make it clear that the API is frozen.
>
>Signed-off-by: Jakub Kicinski <kuba@...nel.org>
>---
>CC: corbet@....net
>CC: linux-doc@...r.kernel.org
>---
> Documentation/networking/index.rst |  1 +  Documentation/networking/sriov.rst
>| 25 +++++++++++++++++++++++++
> 2 files changed, 26 insertions(+)
> create mode 100644 Documentation/networking/sriov.rst
>
>diff --git a/Documentation/networking/index.rst
>b/Documentation/networking/index.rst
>index a6443851a142..b4b2a002f183 100644
>--- a/Documentation/networking/index.rst
>+++ b/Documentation/networking/index.rst
>@@ -105,6 +105,7 @@ Refer to :ref:`netdev-FAQ` for a guide on netdev
>development process specifics.
>    seg6-sysctl
>    skbuff
>    smc-sysctl
>+   sriov
>    statistics
>    strparser
>    switchdev
>diff --git a/Documentation/networking/sriov.rst
>b/Documentation/networking/sriov.rst
>new file mode 100644
>index 000000000000..652ffb501e6b
>--- /dev/null
>+++ b/Documentation/networking/sriov.rst
>@@ -0,0 +1,25 @@
>+.. SPDX-License-Identifier: GPL-2.0
>+
>+===============
>+NIC SR-IOV APIs
>+===============
>+
>+Modern NICs are strongly encouraged to focus on implementing the
>+``switchdev`` model (see :ref:`switchdev`) to configure forwarding and
>+security of SR-IOV functionality.
>+
>+Legacy API
>+==========
>+
>+The old SR-IOV API is implemented in ``rtnetlink`` Netlink family as
>+part of the ``RTM_GETLINK`` and ``RTM_SETLINK`` commands. On the driver
>+side it consists of a number of ``ndo_set_vf_*`` and ``ndo_get_vf_*`` callbacks.
>+
>+Since the legacy APIs does not integrate well with the rest of the
>+stack the API is considered frozen, no new functionality or extensions
>+will be accepted. New drivers should not implement the uncommon
>+callbacks, namely the following callbacks are off limits:
>+
>+ - ``ndo_get_vf_port``
>+ - ``ndo_set_vf_port``
>+ - ``ndo_set_vf_rss_query_en``
>--
>2.45.2
>

Does this mean 
ndo_set_vf_mac
ndo_set_vf_vlan
etc
will be allowed for new drivers ?

Thanks,
Sunil.