DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH 0/1] proposed minor change in rte_flow_validate semantics
@ 2017-03-24  2:36 John Daley
  2017-03-24  2:36 ` [dpdk-dev] [PATCH 1/1] ethdev: don't consider device state when validating flows John Daley
  2017-03-24  9:46 ` [dpdk-dev] [PATCH 0/1] proposed minor change in rte_flow_validate semantics Adrien Mazarguil
  0 siblings, 2 replies; 12+ messages in thread
From: John Daley @ 2017-03-24  2:36 UTC (permalink / raw)
  To: adrien.mazarguil; +Cc: dev, 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

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2017-04-21  8:42 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-24  2:36 [dpdk-dev] [PATCH 0/1] proposed minor change in rte_flow_validate semantics John Daley
2017-03-24  2:36 ` [dpdk-dev] [PATCH 1/1] ethdev: don't consider device state when validating flows John Daley
2017-04-06 20:50   ` Thomas Monjalon
2017-04-06 22:41   ` [dpdk-dev] [PATCH v2 0/1] fix flow validate comments John Daley
2017-04-06 22:41     ` [dpdk-dev] [PATCH v2 1/1] ethdev: " John Daley
2017-04-07  0:23       ` [dpdk-dev] [PATCH v3] " John Daley
2017-04-11 10:01         ` Adrien Mazarguil
2017-04-20 18:49         ` [dpdk-dev] [PATCH v4] doc: " John Daley
2017-04-21  8:11           ` Adrien Mazarguil
2017-04-21  8:42             ` Thomas Monjalon
2017-03-24  9:46 ` [dpdk-dev] [PATCH 0/1] proposed minor change in rte_flow_validate semantics Adrien Mazarguil
2017-03-24 17:23   ` John Daley (johndale)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).