[dpdk-dev] Querying for rte_flow support?

[dpdk-dev] Querying for rte_flow support?

[Stephen Hemminger]

Have a problem with auto-detecting whether device driver supports rte_flow.

Ideally in application would like to be able adapt to handle devices that
do rte_flow and those that do not.  If device does not support rte_flow,
then configure with RSS across multiple cores; if device does support rte_flow
then assign traffic to queue based on match (on MAC).

The problem is that there really is not a good API in DPDK for checking.
Most device drivers will not give the correct return to rte_flow_validate
unless the device is configured already, and some require device to be started.
In order to configure, the application has to choose how many queues to use
and that is the reason it wants to know if rte_flow will work!

The other alternative is looking at DPDK internal data structs to see
if device supports flow operations. That is not good, and causes more
issues in later releases.

Looks like rte_flow has a "chicken/egg problem" here.

Re: [dpdk-dev] Querying for rte_flow support?

[Thomas Monjalon]

29/09/2021 19:44, Stephen Hemminger:
> Have a problem with auto-detecting whether device driver supports rte_flow.
> 
> Ideally in application would like to be able adapt to handle devices that
> do rte_flow and those that do not.  If device does not support rte_flow,
> then configure with RSS across multiple cores; if device does support rte_flow
> then assign traffic to queue based on match (on MAC).
> 
> The problem is that there really is not a good API in DPDK for checking.
> Most device drivers will not give the correct return to rte_flow_validate
> unless the device is configured already, and some require device to be started.
> In order to configure, the application has to choose how many queues to use
> and that is the reason it wants to know if rte_flow will work!
> 
> The other alternative is looking at DPDK internal data structs to see
> if device supports flow operations. That is not good, and causes more
> issues in later releases.
> 
> Looks like rte_flow has a "chicken/egg problem" here.

I think we just need to fix drivers implementation of rte_flow_validate().
We must be able to validate a flow before starting the device.
Which drivers are refusing such check?
That's something we can check with some unit tests.

Re: [dpdk-dev] Querying for rte_flow support?

[Stephen Hemminger]

On Wed, 29 Sep 2021 20:52:43 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 29/09/2021 19:44, Stephen Hemminger:
> > Have a problem with auto-detecting whether device driver supports rte_flow.
> > 
> > Ideally in application would like to be able adapt to handle devices that
> > do rte_flow and those that do not.  If device does not support rte_flow,
> > then configure with RSS across multiple cores; if device does support rte_flow
> > then assign traffic to queue based on match (on MAC).
> > 
> > The problem is that there really is not a good API in DPDK for checking.
> > Most device drivers will not give the correct return to rte_flow_validate
> > unless the device is configured already, and some require device to be started.
> > In order to configure, the application has to choose how many queues to use
> > and that is the reason it wants to know if rte_flow will work!
> > 
> > The other alternative is looking at DPDK internal data structs to see
> > if device supports flow operations. That is not good, and causes more
> > issues in later releases.
> > 
> > Looks like rte_flow has a "chicken/egg problem" here.  
> 
> I think we just need to fix drivers implementation of rte_flow_validate().
> We must be able to validate a flow before starting the device.
> Which drivers are refusing such check?
> That's something we can check with some unit tests.
> 
> 

The issue is with Broadcom but I see it with others.
Mostly because they validate the queue id in the flow request.