From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 418AEC36C for ; Fri, 10 Jul 2015 15:52:49 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 10 Jul 2015 06:52:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,446,1432623600"; d="scan'208";a="744475247" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga001.fm.intel.com with ESMTP; 10 Jul 2015 06:52:33 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.216]) by IRSMSX107.ger.corp.intel.com ([169.254.10.39]) with mapi id 14.03.0224.002; Fri, 10 Jul 2015 14:52:32 +0100 From: "Mcnamara, John" To: Thomas Monjalon Thread-Topic: Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order Thread-Index: AQHQtQq6522JRvZBpUKYMH/FZfH73Z3UuZCQ///zFQCAABVvcA== Date: Fri, 10 Jul 2015 13:52:32 +0000 Message-ID: References: <5006330.bOZQCtd0U5@xps13> In-Reply-To: <5006330.bOZQCtd0U5@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 13:52:49 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, July 10, 2015 2:24 PM > To: Mcnamara, John > Cc: Sanford, Robert; Richardson, Bruce; dev@dpdk.org > Subject: Re: Ethernet API - multiple post-RX-burst callbacks' run-order i= s > opposite to their add-order Hi Thomas, > > Don't hesitate to use Suggested-by: to give credits. I wasn't aware of that. I'll use it in future. > > If the patch is accepted I'll add a note to the release notes also. >=20 > Why not doing the release notes change atomicly in the same patch? Mainly, because there isn't currently a clear place to do that in the relea= se notes. I could change the "New Features" section to "New Features in 2.0= " and then add a "New Features in 2.1". Or perhaps this needs to go into a = "Changed Features in 2.1" section. If you have a suggestion I'll follow it. And I support your previous suggestion of updating the release notes in pat= chsets. That would make things easier for the release notes maintainers (me= and you mainly). Perhaps I'll kick off a separate thread of discussion on refactoring the re= lease notes to make them more useful and easier to update. John. --=20 =20