Wednesday, September 13, 2017 12:28 PM, Thomas Monjalon: > 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).
The issue is, that there is some functionality which cannot be achieved when configuring offload per queue. For example - vlan filter on intel NICs. The PF can set it even without creating a single queue, in order to enable it for the VFs. To make it right, such functionality resides on per-device offloads. However we cannot have such concept on ethdev layer. Also not sure we want to modify the eal for that. > > 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.
