Wednesday, September 13, 2017 3:42 PM, Thomas MonjalonL > 13/09/2017 13:16, Shahaf Shuler: > > 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. > > As it is a device-specific - not documented - side effect, I won't consider > it. > However I understand it may be better to be able to configure per-port > offloads with a dedicated per-port function. > I agree with the approach of the v3 of this series. > > Let me give my overview of offloads: > > We have simple offloads which are configured by just setting a flag. > The same flag can be set per-port or per-queue. > This offload can be set before starting or on the fly. > We currently have no generic way to set it on the fly. > > We have also more complicate offloads which require more configuration. > They are set with the rte_flow API. > They can be per-port, per-queue, on the fly or not (AFAIK). > > I think we must discuss "on the fly" capability. > It requires probably to set up simple offloads (flags) with a dedicated > function instead of using "configure" and "queue_setup" functions. > This new capability can be implemented in a different series. > > Opinions?
Agree about the on the fly configuration for Tx/Rx offloads. Currently the vlan case is an exception, we should have a generic API to set such offloads. I assume that we also don't want to have dev_op function on PMD for each "on the flight" configuration like we have with the vlan offloads.
