From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0049.outbound.protection.outlook.com [104.47.42.49]) by dpdk.org (Postfix) with ESMTP id 2F48423D for ; Mon, 18 Dec 2017 17:39:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hDGRhddYgJz41ypTkbsz9zqpFLjo8uzLL5wfoiM0Lto=; b=Wy4WGigvvjXeMXuzJCYaaDZ7xupUN0tQh+YsHzcy7JpfbktD67JZdSwSiDKVC9qloXj112JgcBpGoFq9OT4VcX//aN3MgEIzUYKjB74EcvbaarnP/AtoEQrXi0HJMP01d1312q/RpjQPqDN/h6qFV8SCVHCG1i7Czzfy36X5gJc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (122.167.86.17) by CO2PR07MB2517.namprd07.prod.outlook.com (10.166.200.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Mon, 18 Dec 2017 16:39:00 +0000 Date: Mon, 18 Dec 2017 22:08:43 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" Cc: "dev@dpdk.org" , "shahafs@mellanox.com" Message-ID: <20171218163842.GA19052@jerin> References: <1512140112-13067-1-git-send-email-konstantin.ananyev@intel.com> <20171214045408.GA843@jerin> <2601191342CEEE43887BDE71AB9772585FAC98BC@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAC98BC@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.9.2 (2017-12-15) X-Originating-IP: [122.167.86.17] X-ClientProxiedBy: MA1PR0101CA0005.INDPRD01.PROD.OUTLOOK.COM (52.134.136.143) To CO2PR07MB2517.namprd07.prod.outlook.com (10.166.200.151) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1c0bd6bb-2eda-4b6f-cce0-08d54635d858 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:CO2PR07MB2517; X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2517; 3:zKSPk3r7rY9gpbgNUoc5o0EPuvtqJt2Fjh7tVtjJwPHiOkp1aHptKDMdM+CgqSEztdrUFm5DnKjpPYUtx3cXkDpuhT5bjaIiW7iE2qdQq8c7WCIuRMYMzJBqsbqJ5/SpkQ6aQaKvyZvy9J/VS2S7wAbw98LjWP4yhWQVAsoQNWa+sJfUNrxN8nMl1PcUoxriHkDIVSw3wiZdheb4JKnYVO6e9WsTMMsSe8vf3O5lWkMJ7H8X+vb82OPcnXiF4t1y; 25:N58qOaFJWljciUJ/rtu1z19iqOyPLvuwiftU0YPCmCNE6SnCBk2g6f4N+d6iXY5f/N/rMGL/g3MeisRp40922onH3PGPk8xlgnNlsQSM5k7gKRb4kCXkU+W4Oq1986Li/QM4DaGWgS+lm+0eTIyryAD1f32bWaf6rYp5S+AeORecgOgYk4gOkVzLFmowXju100AHUcKyR6rjO94OMghQy37kRDlO1PbOa9OOG/nPLJkNNXZ5MPFnZz9Q/NvdB2DJ1it7Tx97YZZ+fe+qRMFBZNCy9OPK9tytUC5O11647EphvKsHaE2lrmngjaBug+ISTA9+TGVOnhGrTuAF/8bREQ==; 31:ce5Ha+3VXUC2P8ZCCd2WPhXQk8q2ed6rMxMjcxtMneBezxYQNXLtn4ZiQAIy7ZBWRr6Ro7LRQCsKj43V7iDIhldPB6dYZasyXXpqL4AeqhHngUpxqKJ+HZZSoA82nkKquuoLnW837jJ2QFZXp9tnRZby2l+fzgeYsP0k/Uwqzi2x71UEfQuIWALxpN5jMfiWI+rJS/Xn8Wssvq/7yY0F9aIi3DRlAD65+UcdGVJF09Y= X-MS-TrafficTypeDiagnostic: CO2PR07MB2517: X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2517; 20:qdygWzRHMDOPOC1sFLrZgma/6ye5s5FZzsFkMb+TfY0dbrLJOjw3puFh2zQ0rSgSnniXfgAJhzxW633Wmcm80nvAAb1Cc2CnfSrPSRtStCN0ESVFI0S8ekt9T+dGHegggHqpwPaizOVYS0LZ3mQzbKe0bWbV7Gpu1Qz3oUkAAAeFW4AoIVry6ANNtPKHt2Y/amIIJJHU6bt/25zOdIREkNK9oUdE5jXt9kk3czZ0GkO6bjwm2U/yxAJPcbHFPTZSVy+AIveX2DHj74mLpRwW/jSE5qJXpGxtkwhZL1zbfpi8+8nTb5jruZb734U8CNhGBU4ZA8sSKJWtftni9eV7ZZ8kLBlqRlTXT48gDDPeSEN83sSlgi5cnQBOdG1ixsyLVj+KfQ4oKR51B41LbDEcD7AeF4KMTQ0fSBg1CPg/liGbnGmEK4Thrd8SdJMDKghmhNeSuOAPKW86+6BkGgSjhdp1muyo1D7yowURAOImN/fB+NXUJNCK/yVwT+8+DaMcNuWZgcFg/wrIkCo0F4rWq402J60d6NP163q0R3kmgwnJFSndfmZz9KsE14CmdN+6uaxut+j4l2cYlMWZwmFlDAlTE0Mj+nes/hgpbH00ErM= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(228905959029699)(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(3002001)(10201501046)(3231023)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CO2PR07MB2517; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CO2PR07MB2517; X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2517; 4:llhR6rBWd73asZqViFBrwl3pWDnSccOLb3wIo4SD+A1Iee1sTxPOiPFo2BpX9zD7tx0Zd6x2OQqJU9ik8dWWi4IwkT1e0s2JrVwsuUTuxK+08iI3PauceySOpvDxeyx0coJP0RS8HTQfJvLR0dLrHBIEAK3WJGyxtLKHYYO9fsxbVzUAj3py7Qv5ChjV9MxdZRKC00F/s+ZBalAkm6ZgkhM+QO/rJlNcpTR1A3Iq66XW4z1FQYHoCJGo78fNYn7cIBlP2GtoQ/STKwptGixurT6JHAJ6JJURpTYLmuywWFMbTVKH55xq1XJurgn1qpTdNlrIgrU0ESaxKSyPV4n7moT1OMw9FE2ejj5lNAVZzaU= X-Forefront-PRVS: 0525BB0ADF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(366004)(396003)(13464003)(199004)(189003)(229853002)(6916009)(16526018)(81156014)(72206003)(42882006)(55016002)(1076002)(47776003)(6246003)(5660300001)(6666003)(2950100002)(8676002)(305945005)(83506002)(52116002)(23726003)(25786009)(6496006)(76176011)(33896004)(81166006)(2906002)(6116002)(3846002)(316002)(8936002)(66066001)(106356001)(7736002)(16586007)(6306002)(33716001)(966005)(105586002)(4326008)(97736004)(9686003)(33656002)(50466002)(54906003)(53376002)(53936002)(478600001)(59450400001)(68736007)(58126008)(386003)(18370500001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR07MB2517; H:jerin; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR07MB2517; 23:5FnMvtvEq7kDobCIWzKWCjvBwAl/x7cqjT//fHi51?= =?us-ascii?Q?Ajq2gyWFEJWzZQ9wAfJiv85PE3t0suir0cTl+0h0POTE1WlCD1QLc9odTEkb?= =?us-ascii?Q?JZVEAlSC0D3+6N3mgYoptO6JAJunthVA60dPCUDsa/x4Itmjm74Af3xAkwwz?= =?us-ascii?Q?GZJIyBYXZalLS7nVvWaQ0Y+G+KrJtNCcxEewFml5gFG6Sf+EcmkodgSVTldz?= =?us-ascii?Q?hCbIDDnG6J56Db5DtRXsg//JvnJfOqVCDMkcFj+haZ564fn1rytxNKgFYNKZ?= =?us-ascii?Q?sdPk/EIu9JnIAT1hwiF4N8x+Qg/ZYr7hZre/o4JVgDoSiWw6Go2KgRWHKTkk?= =?us-ascii?Q?2XJs9+HIcf0m3jNHBKyKtKDFuXD6fNGhWr8knRvNuPtBiIzYfPkd1PPRIdWd?= =?us-ascii?Q?3mKQZJwa+ND6g0Zc8afIMDUdSfyd31vZW0uSsfWak9SS3tXii2K49RooMGVH?= =?us-ascii?Q?Ll4TYLavp7jd7mObFGDbj8VKImjxd65sfvB30zRLsBeTyKdyFHqH7ZVw3n8H?= =?us-ascii?Q?bLTVamDhHR1/my04P61Gh+55Rqlvlg/E/7kIwgQ6syyYix42CTZrkZv0A5w8?= =?us-ascii?Q?/gCZ0RKxHi99SxzjEPejtAqtvX5cjfhDR04hjrxL3FN1NYwat5uZBnmr6Ur1?= =?us-ascii?Q?428dsRHLZpDUSr7z5RbxGKaLxa1cFAFXq9osVI25jfnh1F16Ha74TmtqayDq?= =?us-ascii?Q?M65TeQI4tZrqJmBFwhv03QnbPStgW1xUc4gIzoLa6Jtf1M6YyGd3vWSKla2v?= =?us-ascii?Q?2grnvoK9Xg0/y/7RY1S+vueF9lskPnqYeLoCLw+NSCnsl/fJZAVvBR4CgoMk?= =?us-ascii?Q?yxtUWFfTF4cWYdLWSmT5KkNNvrQEN9UUMoG2Z7ekee4fdO9Zkb82Sfzkzazs?= =?us-ascii?Q?ybJidEi2Pe4+6qkwPR0HvbtpExEnzlhfrwjGXfWDV94LLcHOD5GD4Q6gcUNk?= =?us-ascii?Q?8IED3A2ILWd+Tif1jPpp794wnVsoJI7T6X8suqeXacbtM5GTclry9HF+kQ6K?= =?us-ascii?Q?o9fRWHrN+lET0JXpzlKFTlYFg/A2Ta6CdcM6yl38yNLlN+IrqliBo8QpISx6?= =?us-ascii?Q?Zy0nmEYbbGzOnQVmrzr0gmSju1OMZZT1SWAPTjJe7ZFHTGFxpd/DqhPblK/7?= =?us-ascii?Q?GWpCxCS16e7FMuDWlaDUcNDyk0CfKrp0yTKbwQ7jaBPgEpxvJZ+q0a0oUSX8?= =?us-ascii?Q?E1J2/PV3n5xoIR7ikmRym2NWQiSvusIxFg+cu724nnfPR4H9IfNPNwVYx0at?= =?us-ascii?Q?3byf9dd0zDvWW0QNKPc9VkuLFE+qGV+/PKnf72nCL781sL0rpYaUkrc1INji?= =?us-ascii?Q?vrJrZguur062pOWNJUoG1zbTgPK6t+VPUjiQKH6ml6X?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2517; 6:EBP66gSgLDr17ffHirtK8dbKgH4Fr9QSQeiJG/N7RHrB8SAt6lJ9E/kyBoHFpdTjfmiqFGId7ELw8X89zTRl4X7hTNUlscBcj0DlMtSsLMNJoK554SrE//I1roYLQUw31/RIRvo4b/1sd8QD5h+Kl05dxGIvPsJf1lizGa8n6gRnKETUFwv7o6AxGc8G6KmMgA8O0CiEh6SUdPRGEbO4TcaFxRxnady5YpDM01pdAF/xo3KN8nrL9jIlys2ce0BqcLLo3myZbWiUgZfjTxyREgeTWa2gjZVStXlue8VxierxpH8z079Ob0Jyn6fUZUotV8yQxKhSWIwa1JAIJLoc4hgsoMHgHr9Zx8vLcp1nQkE=; 5:qFG5QkHgJQmlsw956zFkmrgGoowVdnTKE7oSfXCOvfaeXYVs6BWPcZOyQ7DIgd4+0RAyD9D2LQ9CcvywB2s4z3cpkKZOLR0ynivAVo5TIWRnEPMr5/ZR4P/u+KISeRhmei+PXJoFk0J7CKuLKIwSthS6RWZ79OovDpNuNSfjpmc=; 24:jrx1+7xNMuLaAOpedcAzB14Mj6V4JaDxuni6QLpsrL2lmEzXr0GqWlvsVCD4eSt/k76ow0+PEfik+7BGD8danK+YpFJVcXQM7bDPBE2vdwM=; 7:Jar3cU6Z+Y+Fw+WPgPv6PLhUMrC+jrw5vK91tLFnmUrQ8msWrSjGZxGAjilHT/KqtX4xJbQXShGBxl2UWA972l/W1nGouk9mpQh7RLS/aDjkCq/J+ilYwv011cgkbRau6hvDRBwgFieo91tbx1oYxFiPxOOn9joaDi7o5qqSCeWi6WSJ1CWVEfHpeh4T13fruEg+5AiN/EfsSUe5hdUkz0lyZ5PQBULP3NR9TXWzcqzd5zZ363cCJcByZVoAaH9+ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2017 16:39:00.6733 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1c0bd6bb-2eda-4b6f-cce0-08d54635d858 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR07MB2517 Subject: Re: [dpdk-dev] [RFC PATCH 0/3] ethdev: few changes in rte_ethdev layer 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, 18 Dec 2017 16:39:04 -0000 -----Original Message----- > Date: Thu, 14 Dec 2017 13:57:02 +0000 > From: "Ananyev, Konstantin" > To: Jerin Jacob > CC: "dev@dpdk.org" , "shahafs@mellanox.com" > > Subject: RE: [dpdk-dev] [RFC PATCH 0/3] ethdev: few changes in rte_ethdev > layer > > Hi Jerin, Hi Konstantin, > > > > > Hi Konstantin, > > > > > The series introduces 2 main changes: > > > > > > 1.Introduce a separate data structure (rte_eth_queue_local) > > > to store local to given process (i.e. no-shareable) information > > > for each configured rx/tx queue. > > > Memory for that structure is allocated/freed dynamically during > > > rte_eth_dev_configure(). > > > Reserve a space for queue specific (rx|tx)_pkt_burst(), > > > tx_pkt_prepare() function pointers inside that structure. > > > Move rx/tx callback related information inside that structure. > > > That introduces a change in current behavior: all callbacks for > > > un-configured queues will be automatically removed. > > > Also as size of struct rte_eth_dev changes that patch is an ABI breakage, > > > so deprecation notice for 18.05 is filled. > > > Further suggestions how to introduce the same functionality > > > without ABI breakage are welcome. > > > > Are we doing this to enable, Tx/Rx queue specific burst functions to > > invoke based on new TX/RX queue specific offloads framework. > > Meaning, if a offload configured for the given queue, > > driver can select a different function pointer for Rx/Tx burst functions. > > Yes that's the stretch goal. > We do need some extra space for rx/tx callbacks (use field) that needs to > be cache aligned and we plan to make rx/tx function per queue. > So I thought it would be a good opportunity to do these 2 things in one go - > to minimize number of ABI breakages. Makes sense. > > > > > > > > > 2. Make it safe to remove rx/tx callback at runtime. > > > Right now it is not possible for the application to figure out > > > when it is safe to free removed callback handle and > > > associated with it resources(unless the queue is stopped). > > > That's probably not a big problem if all callbacks are static > > > hange through whole application lifetime) > > > and/or application doesn't allocate any resources for the callback handler. > > > Though if callbacks have to be added/removed dynamically and > > > callback handler would require more resources to operate properly - > > > then it might become an issue. > > > So patch #2 fixes that problem - now as soon as > > > rte_eth_remove_(rx|tx)_callback() completes successfully, application > > > can safely free all associated with the removed callback resources. > > > > > > Performance impact: > > > If application doesn't use RX/TX callbacks, then the tests I run didn't > > > reveal any performance degradation. > > > Though if application do use RX/TX callbacks - patch #2 does introduce > > > some slowdown. > > > > > > To be more specific here, on BDW (E5-2699 v4) 2.2GHz, 4x10Gb (X520-4) > > > with http://dpdk.org/dev/patchwork/patch/31864/ patch installed I got: > > > 1) testpmd ... --latencystats=1 - slowdown < 1% > > > 2) examples//l3fwd ... --parse-ptype - - slowdown < 1% > > > 3) examples/rxtx_callbacks - slowdown ~8% > > > All that in terms of packet throughput (Mpps). > > > > We tried on an arm64 machine; We got following result on host and guest > > using l3fwd. > > Thanks for testing it. > So these numbers below - are for l3fwd running with or without rx callback installed? > i.e. with or without '--parse-ptype' option (and on a NIC with/without ptype HW support)? without '--parse-ptype' option(i.e without rx callback installed). That makes it sad, Even though application is not using the rx callback, We need to pay on a average 3% drop in performance(based on the use case/arch/SoC/topology etc) > > > > > > > Note: > > +ve number means "Performance regression with patches" > > -ve number means "Performance improvement with patches" > > > > Relative performance difference in percentage: > > > > % difference on host (2 x 40G) > > pkt_sz 1c 2c 4c 8c > > 64 1.41 0.18 0.51 0.29 > > 72 0.50 0.53 0.09 0.19 > > 128 0.31 0.31 0.42 0.00 > > 256 -0.44 -0.44 0.00 0.00 > > 512 1.94 1.94 0.01 0.01 > > 1024 0.00 0.01 0.00 0.01 > > 1518 0.02 0.01 0.02 0.02 > > > > % difference on guest (2 x 40G) > > pkt_sz 1c 2c 4c 8c > > 64 5.78 2.30 -2.45 -0.01 > > 72 1.13 1.13 1.31 -4.29 > > 128 1.36 1.36 1.54 -0.82 > > 256 2.02 2.03 -0.01 -0.35 > > 512 4.05 4.04 0.00 -0.46 > > 1024 0.39 0.38 0.00 -0.74 > > 1518 0.00 0.00 -0.05 -4.20 > > > > I think, it is because we added more code under > > the RTE_ETHDEV_RXTX_CALLBACKS and it is enabled by > > default. > > > > I think, the impact will vary based on > > architecture and underneath i-cache, d-cache and IPC. > > > > I am just thinking, How we can avoid such impact? > > How about, > > # Remove RTE_ETHDEV_RXTX_CALLBACKS option > > # Hook Rx/TX callbacks under TX/RX offload flags > > # ethdev layer gives helper function to invoke > > callbacks to driver. > > I suppose you suggest that user would have to decide at queue_setup() > stage does he wants a callback(s) for RX/TX or no? Yes. queue_setup or configure() time. > As I can see, the main drawback with that approach - it would introduce new limitation. > Right now it is possible to add/remove RX/TX callback at runtime > (without stopping and reconfiguring the queue), and I suppose we do want to keep that ability. For those _application_ where it can not decide or it need to add without stopping and re configuring the queue still can configure/enable the ethdev device with RX/TX callback option(and pay price for it) > Again in some cases user can't decide does he wants a callback installed or not, > before he actually calls dev_start(). > l3fwd ptype-parse callback is an example of such situation: > right now user has to start device first to figure out which ptypes are supported by this PMD > with desired configuration, then based on this information he will (or will not) setup the callback. Good point. Can we remove that limitation from PMD perspective? IMO, ptype-parse is more of HW feature, All we need to do a lookup(single load) to convert to DPDK packet type. http://dpdk.org/browse/dpdk/tree/drivers/net/thunderx/nicvf_rxtx.c#n258 I see almost all the drivers has dummy check like this, I think, That makes it dependency with start(). if (dev->rx_pkt_burst == i40e_recv_pkts || dev->rx_pkt_burst == i40e_recv_pkts_bulk_alloc || dev->rx_pkt_burst == i40e_recv_scattered_pkts || dev->rx_pkt_burst == i40e_recv_scattered_pkts_vec || dev->rx_pkt_burst == i40e_recv_pkts_vec) return ptypes; > What I thought in same direction - introduce a notion of 'static' and 'dynamic' callbacks. > Static ones can't be removed while queue is not stopped while dynamic can. > But that also requires user to select at queue_setup() stage does he wants dynamic > callbacks for that queue or not (new offload flag or extra field in rxconf/txconf structure). > So again - same limitation for the user. > Another possibility here - have a flag 'dynamic' or 'static' not per queue, but per individual callback. > Yes, that would mean API change for add/remove callback functions. At least on my test, the regression was caused because adding the code in tx_burst and rx_burst under the RTE_ETHDEV_RXTX_CALLBACKS(which enabled by default). By disabling the RTE_ETHDEV_RXTX_CALLBACKS option, I don't see any regression. If so, Will such regression fixed by introducing 'static' or 'dynamic' callbacks? I am happy to test and provide feedback. For me, I think, The better option is request from application for the need for Rx/TX callbacks and set the handler appropriate in the driver to have zero impact for the application which does not need callback at all. at minimum, on those PMDs that support detecting the supported ptypes without device start() > > Konstantin > > > But, don't invoke from common code > > # When application needs the callback support, it > > configured the given RX/TX queue offloads > > # If the Rx/TX callback configure by the application > > then driver calls the helper functions exposed by > > the common code to invoke RX callbacks. > > > > > > Jerin > > > > > > > > Ability to safely remove callbacks at runtime implies > > > some sort of synchronization. > > > Even I tried to make it as light as possible, > > > probably some slowdown is unavoidable. > > > Of course instead of introducing these changes at rte_ethdev layer > > > similar technique could be applied on individual callback basis. > > > In that case it would be up to callback writer/installer to decide > > > does he/she need a removable at runtime callback or not. > > > Though in that case, each installed callback might introduce extra > > > synchronization overhead and slowdown. > > > > > > Konstantin Ananyev (3): > > > ethdev: introduce eth_queue_local > > > ethdev: make it safe to remove rx/tx callback at runtime > > > doc: ethdev ABI change deprecation notice > > > > > > doc/guides/rel_notes/deprecation.rst | 5 + > > > lib/librte_ether/rte_ethdev.c | 390 ++++++++++++++++++++++------------- > > > lib/librte_ether/rte_ethdev.h | 174 ++++++++++++---- > > > 3 files changed, 387 insertions(+), 182 deletions(-) > > > > > > -- > > > 2.13.5 > > >