From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by dpdk.org (Postfix) with ESMTP id 15BE369A5 for ; Fri, 24 Mar 2017 03:37:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2553; q=dns/txt; s=iport; t=1490323023; x=1491532623; h=from:to:cc:subject:date:message-id; bh=gGqHLAm72+D16fxMWQfKFcD8yIg1jllLbzX19jMxDAU=; b=Qxy43xYFD6UnfA0TOGB5JvvvWtrzFNma8vC8d4LE68nB1SqcpNWkuW7q ihl9+l+UqFz4S3zMICy8tt/LcdOjixNOQKifvFxlfq0i9uPaPM2ZRhpRk b+2ohwTrqU4gjyTG37qbRntUL2eE9AQPSnHtJqg0+cZ/+LYWMhIA3eQWd s=; X-IronPort-AV: E=Sophos;i="5.36,213,1486425600"; d="scan'208";a="224207592" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2017 02:37:01 +0000 Received: from cisco.com (savbu-usnic-a.cisco.com [10.193.184.48]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2O2b12C008756; Fri, 24 Mar 2017 02:37:01 GMT Received: by cisco.com (Postfix, from userid 392789) id 6212B3FAAF12; Thu, 23 Mar 2017 19:37:01 -0700 (PDT) From: John Daley To: adrien.mazarguil@6wind.com Cc: dev@dpdk.org, John Daley Date: Thu, 23 Mar 2017 19:36:58 -0700 Message-Id: <20170324023659.28099-1-johndale@cisco.com> X-Mailer: git-send-email 2.12.0 Subject: [dpdk-dev] [PATCH 0/1] proposed minor change in rte_flow_validate semantics X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 02:37:03 -0000 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