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 313AFA0613 for ; Sun, 25 Aug 2019 16:07:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 41EFC1BF8F; Sun, 25 Aug 2019 16:07:00 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150088.outbound.protection.outlook.com [40.107.15.88]) by dpdk.org (Postfix) with ESMTP id 08A021BF8D for ; Sun, 25 Aug 2019 16:06:59 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BTV7U71yS1IASdHgfIcfYvNPyOYMAz4CQVM5hSYERTR82YaH6rEt31gS8f9WBmXk8Lo0mdb8CRqjtr8hIHRSlg2lNDc7Ut2FpOmi+5W30WPBGUWAjSCnUfHF5dlTICAJl9wWYF5X6oCuZ7oSVJfJ87OFhRZfYTcBGNPIB3du904NEb0DC1+4qWvoDDxE6kquI7hk9+baXNGNFpIKrRWpP6+MsXviGxxmva2bskZYw1kyehXX67tCGNXERiuQTmLGiI/UpjgUxBs+i/iRC5ooIth0Elq4sWTg9mqeMpAIQmI3tMMg9xDrqypf9eh7VyZWhlc7eaZP6VwzuMbSSvkB5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f8zxA6n3efamg/1BT6XnHJMUpKejxQXAasS9wrAVo1I=; b=UKidFt2aPzh4wT+XJ/liObSPqxspweICDYK4z55Ij/aOlciQY9FAQjaMWjeG5yOOqlK5UwsxLUsF5/V8T9RM6JaQkGYuyypV3S8RA4u8SwtEVvFdPr3CEQ8WykRulWg1VPMmUo0cSmVjFunyI6m9CmJncKeTEu0fDJDxoAbI2hDb6ptu9HkbaBmXaZ+v2D/TXh2iN95uET8Q5WyrSEyCzoKHN9ZucR5eoghldrOMGyyx3YZNHyu3uoKvmyfYt4tx9lanMvSlGQvgkNphk2UgYVb278yeKy8jpctwpDSWFLGdi52MEc5JY3DD6HXtJQv4YTmK+NULw7iQX/0c5/7JkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f8zxA6n3efamg/1BT6XnHJMUpKejxQXAasS9wrAVo1I=; b=nFpsZ+qcswIgRmZfS1ywbEk2gFYUy80s03400t5qcCHqU7IHYQTpEe/VWlJdrIPxTyTeBlEgE5rrmTJvnYFCwVbzmpjbP7kBKiu0Y+AiU9xojPmysb3+/FHPDAEO/JLd7DO+l4qX+KQE3fKfv2o8NYTXF6yRkJu18eRvpfIC4yg= Received: from AM4PR05MB3425.eurprd05.prod.outlook.com (10.171.190.15) by AM4PR05MB3217.eurprd05.prod.outlook.com (10.171.186.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Sun, 25 Aug 2019 14:06:57 +0000 Received: from AM4PR05MB3425.eurprd05.prod.outlook.com ([fe80::7066:709:7f3c:b84c]) by AM4PR05MB3425.eurprd05.prod.outlook.com ([fe80::7066:709:7f3c:b84c%5]) with mapi id 15.20.2199.021; Sun, 25 Aug 2019 14:06:57 +0000 From: Ori Kam To: Stephen Hemminger CC: Thomas Monjalon , "ferruh.yigit@intel.com" , "arybchenko@solarflare.com" , Shahaf Shuler , Slava Ovsiienko , Alex Rosenbaum , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC] ethdev: support hairpin queue Thread-Index: AQHVUdxZYjq5dQPUn0m0/551v94NJqb5OMaAgADm1OCAAAgZIIAAlVkAgADkO3CAEFcxEA== Date: Sun, 25 Aug 2019 14:06:56 +0000 Message-ID: References: <1565703468-55617-1-git-send-email-orika@mellanox.com> <20190813084619.6b78a7b9@hermes.lan> <20190814075600.1d9bc493@hermes.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=orika@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a133ec16-a944-4298-cf46-08d729657d90 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM4PR05MB3217; x-ms-traffictypediagnostic: AM4PR05MB3217: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01401330D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(13464003)(189003)(199004)(6246003)(11346002)(76176011)(25786009)(52536014)(4326008)(5660300002)(446003)(86362001)(55016002)(33656002)(99286004)(486006)(71200400001)(71190400001)(6436002)(7696005)(476003)(2906002)(53936002)(256004)(14444005)(9686003)(66946007)(66066001)(8936002)(8676002)(81156014)(81166006)(54906003)(478600001)(186003)(76116006)(26005)(66446008)(64756008)(66556008)(66476007)(229853002)(7736002)(74316002)(305945005)(14454004)(3846002)(6116002)(53546011)(6916009)(316002)(102836004)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR05MB3217; H:AM4PR05MB3425.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KpeVkVOeReDWKVsVqRfMrBXNd38/9Yuh3tCvWDFDoITVlTs1cZ/US2AGTNd6TdD0ypdEGJh8iCd4nc+NuydraCwtZfDjRIipOinsh8fqgey392AzFibTeANDi9XzftyhYrQi2tyQy4y/mSs67v8MJQMBRUsu3KO7EJr/AzWqQm2K1Ngbu+CARjV0J49Y8NNP5PuRzMLXAzrGX7DjyCW9IsfYA81OLgKeSY7oZXdpYr0FMHR/D7C4SwvI98Yh2/QAy/QpgHJqRA++QhPIjqLKqGgwG2tX6vAqi+dUhYCepP66VKMWhE9J4SVCe/vZNzi8TZJWpRx/rWPM8Dlj63iKNqypUDBKq1EUz9DOdlJMrGmT+yHqALBIfguORghkhULHEf7XtBouOCRrT32+aoChL4h8ccHKKQHTcHTctHbDCbU= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: a133ec16-a944-4298-cf46-08d729657d90 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2019 14:06:56.9763 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EpPTZN5hrumpifEhwdXslfQRbx+pfdwUa2eLVLMvD/eLUZnQ6sj+jLt3Hf9QOelJZMTginvEUhEYn/NMb9spug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR05MB3217 Subject: Re: [dpdk-dev] [RFC] ethdev: support hairpin queue 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 Stephen, Does my answer resolves your concerns? Thanks, Ori > -----Original Message----- > From: Ori Kam > Sent: Thursday, August 15, 2019 7:42 AM > To: Stephen Hemminger > Cc: Thomas Monjalon ; ferruh.yigit@intel.com; > arybchenko@solarflare.com; Shahaf Shuler ; Slava > Ovsiienko ; Alex Rosenbaum > ; dev@dpdk.org > Subject: RE: [dpdk-dev] [RFC] ethdev: support hairpin queue >=20 >=20 >=20 > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Wednesday, August 14, 2019 5:56 PM > > To: Ori Kam > > Cc: Thomas Monjalon ; ferruh.yigit@intel.com; > > arybchenko@solarflare.com; Shahaf Shuler ; Slava > > Ovsiienko ; Alex Rosenbaum > > ; dev@dpdk.org > > Subject: Re: [dpdk-dev] [RFC] ethdev: support hairpin queue > > > > On Wed, 14 Aug 2019 06:05:13 +0000 > > Ori Kam wrote: > > > > > > -----Original Message----- > > > > From: Ori Kam > > > > Sent: Wednesday, August 14, 2019 8:36 AM > > > > To: Stephen Hemminger > > > > Cc: Thomas Monjalon ; ferruh.yigit@intel.com; > > > > arybchenko@solarflare.com; Shahaf Shuler ; > > Slava > > > > Ovsiienko ; Alex Rosenbaum > > > > ; dev@dpdk.org > > > > Subject: RE: [dpdk-dev] [RFC] ethdev: support hairpin queue > > > > > > > > Hi Stephen, > > > > > > > > > -----Original Message----- > > > > > From: Stephen Hemminger > > > > > Sent: Tuesday, August 13, 2019 6:46 PM > > > > > To: Ori Kam > > > > > Cc: Thomas Monjalon ; ferruh.yigit@intel.com= ; > > > > > arybchenko@solarflare.com; Shahaf Shuler ; > > Slava > > > > > Ovsiienko ; Alex Rosenbaum > > > > > ; dev@dpdk.org > > > > > Subject: Re: [dpdk-dev] [RFC] ethdev: support hairpin queue > > > > > > > > > > On Tue, 13 Aug 2019 13:37:48 +0000 > > > > > Ori Kam wrote: > > > > > > > > > > > This RFC replaces RFC[1]. > > > > > > > > > > > > The hairpin feature (different name can be forward) acts as "bu= mp on > > the > > > > > wire", > > > > > > meaning that a packet that is received from the wire can be mod= ified > > using > > > > > > offloaded action and then sent back to the wire without applica= tion > > > > > intervention > > > > > > which save CPU cycles. > > > > > > > > > > > > The hairpin is the inverse function of loopback in which applic= ation > > > > > > sends a packet then it is received again by the > > > > > > application without being sent to the wire. > > > > > > > > > > > > The hairpin can be used by a number of different NVF, for examp= le > load > > > > > > balancer, gateway and so on. > > > > > > > > > > > > As can be seen from the hairpin description, hairpin is basical= ly RX > > queue > > > > > > connected to TX queue. > > > > > > > > > > > > During the design phase I was thinking of two ways to implement= this > > > > > > feature the first one is adding a new rte flow action. and the = second > > > > > > one is create a special kind of queue. > > > > > > > > > > > > > > > Life would be easier for users if the hairpin was an attribute > > > > > of queue configuration, not a separate API call. > > > > > > > > I was thinking about it. the reason that I split the functions is t= hat they use > > > > different > > > > parameters sets. For example the hairpin queue doesn't need memory > > region > > > > while it does need > > > > the hairpin configuration. So in each case hairpin queue / normal q= ueue > > there > > > > will be > > > > parameters that are not in use. I think this is less preferred. Wha= t do you > > think? > > > > > > > > > > Forgot in my last mail two more reasons I had for this for this: > > > 1. changing to existing function will break API, and will force all a= pplications > > to update date. > > > 2. 2 API are easier to document and explain. > > > 3. the reason stated above that there will be unused parameters in ea= ch > call. > > > > New API's are like system calls, they create longer term support overhe= ad. > > It would be good if there was support for this on multiple NIC types. >=20 > I don't know the capability of other NICs. I think this is a good feature= that can > be embrace > and implemented by other NICS (may be they can even have some SW > implementation for this > that will still use CPU but will give faster packet rate since they know = how their > HW works) > Regarding the long term support, I'm sorry but I don't see the longer sup= port > issue that important since for this > exact reason I think a dedicated API is much easer to maintain. Also my b= e in > future there will be > a new type and then the generic function will have a lot of unused code w= hich > is hard to maintain > and debug. >=20 > Thanks, > Ori