From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 046583237 for ; Wed, 27 Feb 2019 09:57:22 +0100 (CET) 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-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id B7BB1B40066; Wed, 27 Feb 2019 08:57:20 +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; Wed, 27 Feb 2019 08:57:15 +0000 To: Stephen Hemminger , References: <20190226101444.752ee2da@shemminger-XPS-13-9360> From: Andrew Rybchenko Message-ID: <1967530f-6d1b-2895-b3f0-c6863ce6a040@solarflare.com> Date: Wed, 27 Feb 2019 11:57:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190226101444.752ee2da@shemminger-XPS-13-9360> 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-24458.002 X-TM-AS-Result: No-9.590500-8.000000-10 X-TMASE-MatchedRID: HXSqh3WYKfv4ECMHJTM/uSa1MaKuob8PC/ExpXrHizxX14Hy+eYp78Rk oeJ3OFRc38rUHvxowipo4PwuzDPJuwZuQ+SK0t7Obc297PAGtWZ+S5m2/8VLmpUyTIJurbdh4Se rpergeBE1VLtprwJWFrQ0i3HUD1fMNuVzoZ6LieUiPTMUjkOgkl4KsHfYo5LQowtRP8whCK8K8T ry7xT2TxHh35S+GXSq/VWmtOMs6xHeWaJDH5WqDQcbMHjYNxGhhZApJAdFDDabKItl61J/ycnjL TA/UDoA+S9X7PfvVMqOhzOa6g8KrUgCYSsgMPTQIEV36rnYl8tI3hfbBtcA70L2F1V2JbblOJ+0 qojRRxXdCXVQ5eoPaHu9D1cucwPeqy9Dqc8AJ8XEgMUn2cDsJDZFEgw6u+Np X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--9.590500-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24458.002 X-MDID: 1551257841-vzO_VuvXuDAL Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] locking around rx_intr_enable/disable? 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: Wed, 27 Feb 2019 08:57:22 -0000 On 2/26/19 9:14 PM, Stephen Hemminger wrote: > I noticed an anomaly in how receive interrupt control is done. > > In l3fwd-power there is a per-port lock around calls to enable interrupts > but no locking around the call to disable interrupts. This looks broken > since intr_disable requires multiple operations on some hardware. > > There are three better options: > 1) do locking in rte_eth_dev (not application) > 2) push any necessary locking down into the driver > 3) lock on both places in l3fwd-power (and other usages) > > I am thinking #1 is easiest solution. > > Which ever solution is done, the documentation should be as well. I think #2 is a way to go - some drivers require locking, some not. I think it is a bad idea to enforce locking for drivers which do not require it. Andrew.