> -----Original Message----- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Wednesday, September 13, 2017 1:42 PM > To: dev@dpdk.org; Shahaf Shuler <shah...@mellanox.com> > Cc: Ananyev, Konstantin <konstantin.anan...@intel.com>; > step...@networkplumber.org > Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new > offloads API > > 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.
Hmm, are you saying that if there are gaps in our documentation it ok to break things? Once again - you suggest to break existing functionality without providing any alternative way to support it. Surely I will NACK such proposal. Konstantin > 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?
