[dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API

Ananyev, Konstantin konstantin.ananyev at intel.com
Wed Sep 13 14:56:22 CEST 2017



> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Wednesday, September 13, 2017 1:42 PM
> To: dev at dpdk.org; Shahaf Shuler <shahafs at mellanox.com>
> Cc: Ananyev, Konstantin <konstantin.ananyev at intel.com>; stephen at 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?


More information about the dev mailing list