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 278ECA320B for ; Mon, 21 Oct 2019 15:45:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 92D1D1BF49; Mon, 21 Oct 2019 15:45:12 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id EDFC91BF45 for ; Mon, 21 Oct 2019 15:45:10 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2019 06:45:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,323,1566889200"; d="scan'208";a="196112542" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga008.fm.intel.com with ESMTP; 21 Oct 2019 06:45:09 -0700 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 21 Oct 2019 06:45:09 -0700 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 21 Oct 2019 06:45:08 -0700 Received: from bgsmsx106.gar.corp.intel.com (10.223.43.196) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Mon, 21 Oct 2019 06:45:08 -0700 Received: from bgsmsx101.gar.corp.intel.com ([169.254.1.199]) by BGSMSX106.gar.corp.intel.com ([169.254.1.191]) with mapi id 14.03.0439.000; Mon, 21 Oct 2019 19:15:06 +0530 From: "Varghese, Vipin" To: "Richardson, Bruce" CC: "Loftus, Ciara" , 'Stephen Hemminger' , "'dev@dpdk.org'" , "Ye, Xiaolong" , "Laatz, Kevin" , "Yigit, Ferruh" Thread-Topic: [dpdk-dev] [PATCH v2 2/3] net/af_xdp: support pinning of IRQs Thread-Index: AQHVd65xbFLCTXmJzEOr4n4smjb1qadEGKuAgAR3J4CAHBJngIAAifOQ//+oWQCAAF1qkP//pjoAgABjB6A= Date: Mon, 21 Oct 2019 13:45:05 +0000 Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DD007@BGSMSX101.gar.corp.intel.com> References: <20190930164205.19419-1-ciara.loftus@intel.com> <20190930164205.19419-3-ciara.loftus@intel.com> <20190930101137.4919f93e@hermes.lan> <74F120C019F4A64C9B78E802F6AD4CC279226C6C@IRSMSX106.ger.corp.intel.com> <74F120C019F4A64C9B78E802F6AD4CC27924737D@IRSMSX106.ger.corp.intel.com> <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DCF94@BGSMSX101.gar.corp.intel.com> <20191021130416.GB942@bricha3-MOBL.ger.corp.intel.com> <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DCFC2@BGSMSX101.gar.corp.intel.com> <20191021131718.GD942@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20191021131718.GD942@bricha3-MOBL.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZmQ1YjdiMmItOGM2Yy00MGZiLWFmYmEtZTNkODQ5MTNiMzI0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiT3NRK1NBdnk2VUlWa1Z3SWNMVExXVFdDRzdjZlhFQ1ZMVE5DTjFtMmFYVVZ0bmpEXC9wZnBmSkpaclBPaHJ3U2UifQ== dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.223.10.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 2/3] net/af_xdp: support pinning of IRQs 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" Hi Bruce, snipped > > This ability to have the driver pin the interrupts for the > > > user would be a big timesaver for developers too, who may be > > > constantly re- running apps when testing. > > Here my understanding, user can not or should not pass DPDK cores for > interrupt pinning. So should we ask the driver to fetch `rte_eal_configur= ation` > and ensure the same? > > >=20 > Actually I disagree. I think the user should pass the cores for interrupt= pinning, I agree to this. > because unlike other PMDs it is perfectly valid to have the interrupts pi= nned to > dedicated cores separate from those used by DPDK. My point is the same, but not on DPDK DP or service cores. >=20 > Or taking another example, suppose the app takes 8 cores in the coremask,= but > only one of those cores is to be used for I/O, what cores should the driv= er pin > the interrupts to? It can be cores on machine (guest or host) which is not used by DPDK. It probably should be the same core used for I/O, but the > driver can't know which cores will be for that, or alternatively the user= might > want to use AF_XDP split across two cores, in which case any core on the > system might be the intended one for interrupts. I agree to the patch, only difference in dev->probe function, should not th= ere be validation to ensure the IRQ core is not DPDK core or Service core a= s the Interface is owned by kernel and for non matched eBPF skb buff is use= d by kernel.