I still think we must streamline ethdev API instead of complexifying. We should drop the big "configure everything" and configure offloads one by one, and per queue (the finer grain).
More comments below 06/09/2017 11:33, Ananyev, Konstantin: > From: Shahaf Shuler [mailto:shah...@mellanox.com] > > Tuesday, September 5, 2017 6:31 PM, Ananyev, Konstantin: > > > > > > > > > In fact, right now it is possible to query/change these 3 > > > > > > > > > vlan offload flags on the fly (after dev_start) on port > > > > > > > > > basis by > > > > > rte_eth_dev_(get|set)_vlan_offload API. > > > > > > > > Regarding this API from ethdev. > > > > > > > > So this seems like a hack on ethdev. Currently there are 2 ways for > > > > user to > > > set Rx vlan offloads. > > > > One is through dev_configure which require the ports to be stopped. The > > > other is this API which can set even if the port is started. > > > > > > Yes there is an ability to enable/disable VLAN offloads without > > > stop/reconfigure the device. > > > Though I wouldn't call it 'a hack'. > > > From my perspective - it is a useful feature. > > > Same as it is possible in some cases to change MTU without stopping > > > device, > > > etc. I think the function rte_eth_dev_configure(), which set up several things at a time, is a very bad idea from API perspective. In the VLAN example, we should have only one function to set this offload. And the PMD should advertise the capability of configuring VLAN on the fly. This function should return an error if called on the fly (started state) and PMD does not support it. > > > Consider scenario when PF has a corresponding VFs (PF is controlled by > > > DPDK) Right now (at least with Intel HW) it is possible to: > > > > > > struct rte_eth_conf dev_conf; > > > dev_conf. rxmode.hw_vlan_filter = 1; > > > ... > > > rte_eth_dev_configure(pf_port_id, 0, 0, &dev_conf); > > > rte_eth_dev_start(pf_port_id); > > > > > > In that scenario I don't have any RX/TX queues configured. > > > Though I still able to enable vlan filter, and it would work correctly > > > for VFs. > > > Same for other per-port offloads. > > > > For the PF - enabling vlan filtering without any queues means nothing. The > > PF can receive no traffic, what different does it makes the vlan > > filtering is set? > > For the VF - I assume it will have queues, therefore for it vlan filtering > > has a meaning. However as I said above, the VF has the vlan filter > > because in intel this is per-device offload, so this is not a good example. > > Yes it is a per-device offload, and right now it is possible to > enable/disable it via > dev_confgiure(); dev_start(); > without configuring/starting any RX/TX queues. > That's an ability I'd like to preserve. > So from my perspective it is a perfectly valid example. It is configuring VFs by setting the PF. Where is it documented? It looks to me as a device-specific side effect.
