From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 32D7EA04C0; Thu, 17 Sep 2020 17:34:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1E6EE1D67A; Thu, 17 Sep 2020 17:34:15 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 53D2D1D449 for ; Thu, 17 Sep 2020 17:34:13 +0200 (CEST) Received: from mx1-us1.ppe-hosted.com (unknown [10.110.50.144]) by dispatch1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id EA0E7200D8; Thu, 17 Sep 2020 15:34:12 +0000 (UTC) Received: from us4-mdac16-60.at1.mdlocal (unknown [10.110.50.153]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id E7268800A9; Thu, 17 Sep 2020 15:34:12 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.110.49.107]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 64F4E40060; Thu, 17 Sep 2020 15:34:12 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 9155B28008A; Thu, 17 Sep 2020 15:34:08 +0000 (UTC) Received: from [127.0.0.27] (10.17.10.39) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 17 Sep 2020 16:33:52 +0100 To: Ajit Khaparde , Andrey Vesnovaty CC: NBU-Contact-Thomas Monjalon , Ori Kam , Slava Ovsiienko , "jerinj@marvell.com" , Andrew Rybchenko , dpdk-dev , "jer@marvell.com" , Jerin Jacob , Ferruh Yigit , Stephen Hemminger , Bruce Richardson , Ori Kam , Viacheslav Ovsiienko , "andrey.vesnovaty@gmail.com" , Ray Kinsella , Neil Horman , Thomas Monjalon , Samik Gupta References: <20200702120511.16315-1-andreyv@mellanox.com> <20200708213946.30108-1-andreyv@mellanox.com> <20200708213946.30108-2-andreyv@mellanox.com> From: Andrew Rybchenko Message-ID: Date: Thu, 17 Sep 2020 18:33:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.10.39] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.6.1012-25670.006 X-TM-AS-Result: No-7.179800-8.000000-10 X-TMASE-MatchedRID: VPleTT1nwdR0nsJmoztmWPZvT2zYoYOwC/ExpXrHizyPiMW+3YzkgrqS NKTkl986XQS0szagh4NHvPWyFe6hU/3OUDZboT0w1JdCMvZkkjI6En2bnefhoIe/yi1B5QhCZJ2 3hwfoyRtqlM/UPbbakoWSkHf6Tb2DhJOsiG/B2u+KR0fcRBoRNa/WVJNdLUTFQzcrLK1tq+ejxY yRBa/qJQPTK4qtAgwIIC0OoeD/hCbQLWxBF9DMQcRB0bsfrpPIx1FPlNAAmcDUrUBLaYGH4wXMy JNxaW7EDxFGFpr2S9fMvxJiu6zy0Z6oP1a0mRIj X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--7.179800-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.6.1012-25670.006 X-MDID: 1600356852-Uup9mdC4YBCC Subject: Re: [dpdk-dev] [PATCH v2 1/6] ethdev: add flow shared action API 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 9/16/20 10:20 PM, Ajit Khaparde wrote: > On Wed, Sep 16, 2020 at 8:52 AM Andrey Vesnovaty wrote: >> >> Hi Ajit >> >> For shared action configuration I have following suggestion: >> >> struct rte_flow_shared_action_conf { >> uint32_t no_ingress: 1; >> uint32_t no_egress: 1; >> }; >> /*...*/ >> rte_flow_shared_action_create(..., const struct rte_flow_shared_action_conf *conf, ...); >> >> What do you think? > Andrey, I think this is good. > Application can specify the direction and PMD can decide whether if > it needs to honor it or ignore it. > Please send the updated version of the patch. Personally I dislike negative flags, offloads, fields etc. Don't we have a policy to avoid it. At least we have it for offloads. I see no string reasons here to use negative instead of positive here.