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 D229DA3179 for ; Thu, 17 Oct 2019 12:37:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 52BC21E930; Thu, 17 Oct 2019 12:37:27 +0200 (CEST) Received: from dispatchb-us1.ppe-hosted.com (dispatchb-us1.ppe-hosted.com [148.163.129.53]) by dpdk.org (Postfix) with ESMTP id 61B941E547 for ; Thu, 17 Oct 2019 12:37:26 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine 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 72342A80061; Thu, 17 Oct 2019 10:37:24 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 17 Oct 2019 11:37:18 +0100 To: Ferruh Yigit , Ciara Power , CC: , Thomas Monjalon References: <20191016154606.39218-1-ciara.power@intel.com> From: Andrew Rybchenko Message-ID: <5b6af628-7101-484b-01db-16272025105f@solarflare.com> Date: Thu, 17 Oct 2019 13:37:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] 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.5.1010-24982.003 X-TM-AS-Result: No-4.829200-8.000000-10 X-TMASE-MatchedRID: oHOSwQSJZWjmLzc6AOD8DfHkpkyUphL9cVr+FAe3UDUOOOIzzESoE9xw X69jh9hhgLpjL6KnVPOcxc73N69MaYyQUjhAi5+qMpVOsYwN78Py++SyyVe4t70rWM4nIpJrn68 UTiD6dZhh9M64k1dYu85frr4hnN1KgxRTSLSLS/xwju9EALAXQjVvI0Ic6AC1kaEC8FJraL/haP 2JoKUCSe1VmHwWGO0bRodo9/GXhRjNnWwqhmCQdczSKGx9g8xhfkuZtv/FS5qfcVJ8cL8ZOztWz Je6wcdX9MvSNF22SK0L11Qsi8d5hsaZnhgjGx37IAjxomarSPAvsOOmgOo1mW5AmxiyBtC4Oehn WcVBfVbtyiiocwStrVO9V994jC9DaLxhTaCJKI8/ApMPW/xhXkyQ5fRSh2654uxAgOavdLl4pqO 87q5acHI7DORm3u9I6BJFqIUTSFZvAVPVxkfEIdn6L+08IS/JfS0Ip2eEHnzUHQeTVDUrItRnEQ CUU+jzjoczmuoPCq1GeMZru80lQOCww3O8Lqg2gL1SynDm2luwsg7gCHXbupGcRHokpFD4RuVvD axXSNakaVfYSMK1EriHu1/j1p9cjIHggSrotvzi+fTMx9KaNitss6PUa4/cD6GAt+UbooSj1CO4 X0Eqed8x3qzoMNxx X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--4.829200-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24982.003 X-MDID: 1571308645-fyEciMZ6ZQVk Subject: Re: [dpdk-dev] [RFC] net/null: add empty promiscuous mode functions 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 10/16/19 9:07 PM, Ferruh Yigit wrote: > On 10/16/2019 4:46 PM, Ciara Power wrote: >> Adding promiscuous functions prevents sample applications failing when run >> on this virtual PMD. The sample applications call promiscuous functions, >> and fail if this function call returns an error, which occurs when the >> virtual PMD does not support the promiscuous function being called. >> >> This change will be implemented for all virtual PMDs that currently do not >> have existing promiscuous functions. Multicast functions will also be >> added for virtual PMDs to prevent sample application breakages here also. > +Andrew > > With the some ethdev APIs returning error code, some sample applications stop > working with virtual interfaces, > > We can, > 1- update sample applications to ignore the errors > 2- Add dummy dev_ops support to (almost all) virtual PMDs (what this RFC suggests) > > (1) puts us back to before the ethdev APIs updated status, and this may be wrong > for the physical devices case, so I am for this RFC. > > Only perhaps we can have some common empty function and keep assigning that one > to reduce the dummy code, what do you think? I don't like the idea to have common empty/dummy functions. If virtual PMD behaves in accordance with enabled promiscuous mode, it should initialize it properly on init:      eth_dev->data->promiscuous = 1; If so, if application requires promiscuous mode, attempt to enable will do nothing. If application requires non-promiscuous mode, disable will fail and it is good. >> Signed-off-by: Ciara Power >> --- >> drivers/net/null/rte_eth_null.c | 14 ++++++++++++++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c >> index e2ff41a22..b8472a0cf 100644 >> --- a/drivers/net/null/rte_eth_null.c >> +++ b/drivers/net/null/rte_eth_null.c >> @@ -441,11 +441,25 @@ eth_mac_address_set(__rte_unused struct rte_eth_dev *dev, >> return 0; >> } >> >> +static int >> +eth_dev_promiscuous_enable(__rte_unused struct rte_eth_dev *dev) >> +{ >> + return 0; >> +} >> + >> +static int >> +eth_dev_promiscuous_disable(__rte_unused struct rte_eth_dev *dev) >> +{ >> + return 0; >> +} >> + >> static const struct eth_dev_ops ops = { >> .dev_start = eth_dev_start, >> .dev_stop = eth_dev_stop, >> .dev_configure = eth_dev_configure, >> .dev_infos_get = eth_dev_info, >> + .promiscuous_enable = eth_dev_promiscuous_enable, >> + .promiscuous_disable = eth_dev_promiscuous_disable, >> .rx_queue_setup = eth_rx_queue_setup, >> .tx_queue_setup = eth_tx_queue_setup, >> .rx_queue_release = eth_queue_release, >>