From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 923662C18 for ; Mon, 3 Apr 2017 15:30:32 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP; 03 Apr 2017 06:30:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,270,1486454400"; d="scan'208";a="82266104" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga005.jf.intel.com with ESMTP; 03 Apr 2017 06:30:30 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.241]) by irsmsx105.ger.corp.intel.com ([169.254.7.163]) with mapi id 14.03.0319.002; Mon, 3 Apr 2017 14:30:29 +0100 From: "Mcnamara, John" To: "Yigit, Ferruh" , "Yang, Qiming" , "dev@dpdk.org" , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH] doc: add known igb_uio issue for i40e Thread-Index: AQHSptwRsyHpu6HEBECmeC7hDwrisKGzbtSAgAA53ZA= Date: Mon, 3 Apr 2017 13:30:29 +0000 Message-ID: References: <1490606177-38274-1-git-send-email-qiming.yang@intel.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_PUBLIC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzUxOThlODEtOWNlOC00NDM5LWE4YTYtYWQzYjE2NzI4MjdlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiJBNGNlV2h5XC9XK1d4NzJ3MExYVmVBUTJ6UVIwMlFyRXJCODQwbEZEYVRadz0ifQ== x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] doc: add known igb_uio issue for i40e 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, 03 Apr 2017 13:30:33 -0000 > -----Original Message----- > From: Yigit, Ferruh > Sent: Monday, April 3, 2017 11:40 AM > To: Yang, Qiming ; dev@dpdk.org; Mcnamara, John > ; Thomas Monjalon > Subject: Re: [dpdk-dev] [PATCH] doc: add known igb_uio issue for i40e >=20 > On 3/27/2017 10:16 AM, Qiming Yang wrote: > > When insmod "igb_uio" with "intr_mode=3Dlegacy and test link status > > interrupt. Since INTx interrupt is not supported by X710/XL710/XXV710, > > it will cause Input/Output error when reading file descriptor. > > > > Signed-off-by: Qiming Yang > > --- > > doc/guides/nics/i40e.rst | 13 +++++++++++++ >=20 > Hi John, >=20 > There are three different "Known Issue" sections in documentations: >=20 > 1) Known Issues document, doc/guides/rel_notes/known_issues.rst > 2) Release notes, known issues section, > doc/guides/rel_notes/release_17_05.rst > 3) Device specific known issues sections, doc/guides/nics/i40e.rst >=20 >=20 > This patch updates 3), what is the rule on updating those files? >=20 Hi, I was going to make a similar comment on the patchset. Having "known" issues in three places is a good way of keeping them unknown= . Ideally the process should be: 1. Add new "known" issues into the release notes. 2. Move these to known_issues.rst after each release. This is a little too manual, so perhaps known issues should be added direct= ly=20 to known_issues.rst under a header for the release they were identified in. The release notes could contain a link to known_issues.rst. However, this patch adds a third location, the NIC document. I have some sympathy for this approach since the NIC docs generally have a limitations section which is similar to known issues. If we agree that this is a good approach then we should move all of the NIC specific issues to the Limitations sections of the NIC docs and include a section at the start of the "Known Issues" doc to remind users to also check the NIC specific doc. However, I think this needs to be co-ordinated and done in one go. So, for= =20 this release, let's not move the i40e known issues and instead do a general cleanup and refactoring of the "Known Issues" at the very start of the 17.0= 8 cycle. Other opinions? John