Tue, Jun 06, 2017 at 02:01:41AM CEST, [email protected] 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.
