[dpdk-dev] [PATCH 0/1] proposed minor change in rte_flow_validate semantics

[John Daley]

Hi,

In implementing rte_flow_validate() for the Cisco enic, I got to wondering
if the semantics might be slightly off given how I see apps using it.

Please forgive me if this has already been discussed, but during runtime, I
can't see any reason why rte_flow_validate() would be called when
rte_flow_create() returns the same errors as validate, but also creates
the filter if all is good (calling validate first is just extra overhead).
What are the use cases for calling validate when the app is up and running?

I see rte_flow_validate() being run at startup for answering these 2 questions:
1.) Given enough resources, is the device capable of handling flows
a, b, c, ..,  which the app may want to create during runtime?
2.) How many concurrent flows of type a, b, c, .. can the device handle? To
answer this app needs to do a bunch of rte_flow_create()'s (followed by a bunch of rte_flow_destroy()s).

The answer to these questions will allow the app to decide beforehand which
filters to offload (if any) and set up function pointers or whatever to run
as efficiently as possible on the target device.

rte_flow_validate() has comments that imply it should be run on the fly,like
"the flow rule is validated against its current configuration state and the
returned value should be considered valid by the caller for that state only".
The only real way to implement this is for enic (and I think other nics) is
to actually do a flow create/destroy within rte_flow_validate(). But, see
paragraph 2 above- why bother? I looked at the i40e and mlx5 implementations
and I didn't see any calls to the nics to check a flow against current state
so they might not be implemented as the comment imply they should be either.

If there are no use cases for calling validate at runtime,  I think we ought
to change the semantics of rte_flow_validate() a little to define success to
mean that the device will accept the flow IF there are enough resources,
rather than it will accept the flow given the current state. We can safely
remove the -EEXIST return code since no other drivers set them yet. This
makes the function easier to implement correctly without trying to do
something that's not useful anyway.

The following patch just changes comments but I think that is all that is
required.

Thanks,
John

John Daley (1):
  ethdev: don't consider device state when validating flows

 lib/librte_ether/rte_flow.h | 21 +++++----------------
 1 file changed, 5 insertions(+), 16 deletions(-)

-- 
2.12.0