From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 3AFD9160 for ; Mon, 15 Oct 2018 05:00:18 +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 fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2018 20:00:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,383,1534834800"; d="scan'208";a="78759170" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga008.fm.intel.com with ESMTP; 14 Oct 2018 20:00:16 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 14 Oct 2018 20:00:16 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.60]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.245]) with mapi id 14.03.0319.002; Mon, 15 Oct 2018 11:00:15 +0800 From: "Li, Xiaoyun" To: "Zhang, Qi Z" , "Xing, Beilei" , "dev@dpdk.org" , "Lu, Wenzhuo" , "Wu, Jingjing" Thread-Topic: [PATCH v3] doc: add known issue about legacy intr mode for ixgbe Thread-Index: AQHUWGsQTEwcyszJRUuFfyCOd1lYi6UNAzQAgBKrElA= Date: Mon, 15 Oct 2018 03:00:13 +0000 Message-ID: References: <1538039797-43828-1-git-send-email-xiaoyun.li@intel.com> <1538275984-38043-1-git-send-email-xiaoyun.li@intel.com> <039ED4275CED7440929022BC67E70611532A9A2E@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <039ED4275CED7440929022BC67E70611532A9A2E@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3] doc: add known issue about legacy intr mode for ixgbe 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: Mon, 15 Oct 2018 03:00:18 -0000 Hi > > +Do not bind the ``uio_pci_generic`` module in X550 NICs. > > +Do not bind ``igb_uio`` with legacy mode in X550 NICs. > > +Before using ``vfio`` with legacy mode in X550 NICs, using ``modprobe > > +vfio `` ``nointxmask=3D1`` to bind ``vfio``. >=20 > I have couple questions here. > If noinitxmask=3D1 is set, does that mean, in vfio interrupt handler we w= ill not > check intr mask? but what if the intx is shared by another devices? > Does that mean we will also handle interrupt from other devices which is = not > expected? If noinitxmask=3D1 is not set, vfio will check if it has broken intx msking= (which is hardcoded. Only i40e is considered as broken). If it is broken, vfio_intx_handler will disable_irq_nosync and mask this ir= q and then return the efd to userspace. But if it is not broken, vfio_intx_handler will call pci_check_and_set_intx= _mask. In pci_check_and_set_intx_mask, the interrupt status bit is checked. And for X550, vfio thinks it's intx masking is not broken and will check it= s interrupt status bit. But this bit is not enabled in X550 in fact. Then v= fio will think the interrupt isn't triggered and will not deal with it. The= n "nobody cared" issue occurs. But when with nointxmask=3D1, vfio will think the device has broken intx ma= sking. Then will disable_irq_nosync and mask this irq and then return the e= fd to userspace. Since it will disable_irq_nosync, the irq will be affected if it is shared = by another device. >=20 > Not sure if we should add some statement like "if the intx is not shared = with > other device ...." ? Yes. I will add it. >=20 > > > > Inline crypto processing support > > -------------------------------- > > -- > > 2.7.4