netdev - Re: [PATCH net-next 00/16] nfp: ctrl vNIC

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]

Message-ID: <20170606061610.GA1911@nanopsycho>
Date:   Tue, 6 Jun 2017 08:16:10 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     netdev@...r.kernel.org, oss-drivers@...ronome.com
Subject: Re: [PATCH net-next 00/16] nfp: ctrl vNIC

Tue, Jun 06, 2017 at 02:01:41AM CEST, jakub.kicinski@...ronome.com wrote:
>Hi!
>
>This series adds the ability to use one vNIC as a control channel
>for passing messages to and from the application firmware.  The
>implementation restructures the existing netdev vNIC code to be able
>to deal with nfp_nets with netdev pointer set to NULL.  Control vNICs
>are not visible to userspace (other than for dumping ring state), and
>since they don't have netdevs we use a tasklet for RX and simple skb 
>list for TX queuing.
>
>Due to special status of the control vNIC we have to reshuffle the
>init code a bit to make sure control vNIC will be fully brought up
>(and therefore communication with app FW can happen) before any netdev
>or port is visible to user space.
>
>FW will designate which vNIC is supposed to be used as control one
>by setting _pf%u_net_ctrl_bar symbol.  Some FWs depend on metadata
>being prepended to control message, some prefer to look at queue ID
>to decide that something is a control message.  Our implementation
>can cater to both.
>
>First two users of this code will be eBPF maps and flower offloads.

How do you actually do the configuration from the userspace? I did not
find it in the patches.

I'm not really sure that doing it using one "control netdevice" is the
correct way to go. The configuration is asic-wide, should be done by a
devlink parent handle which was introduced for that exact purpose.

Am I missing something? We need to sync in this. In mlxsw we need to do
some pre-netdev configuraton as well.

Thanks.