From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0080.outbound.protection.outlook.com [104.47.1.80]) by dpdk.org (Postfix) with ESMTP id 7E3351BAB6 for ; Wed, 4 Apr 2018 02:12:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8NoUdE/S4Ed5EmLya4UmBMUVSHIY2eQ+lecEwAVhnr4=; b=LCnyRuIWlAnClNAXE8RT7b9BQlsark/+/GGcvK4O5stgQBja/ZD87epRwa+ruWfvLMHPVBo89ywLMVGDi0o7MDEe75Bf/YkL1yCL9h2Zl9CZY99ycCkHKJoYXyfqvYy9vMkLPU6qcQZjt002PHUmy9JbPNGwoj9NDpGfRB8Nsho= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; Received: from yongseok-MBP.local (209.116.155.178) by DB6PR0501MB2039.eurprd05.prod.outlook.com (2603:10a6:4:6::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Wed, 4 Apr 2018 00:12:19 +0000 Date: Tue, 3 Apr 2018 17:12:06 -0700 From: Yongseok Koh To: Olivier Matz Cc: wenzhuo.lu@intel.com, jingjing.wu@intel.com, adrien.mazarguil@6wind.com, nelio.laranjeiro@6wind.com, dev@dpdk.org Message-ID: <20180404001205.GB1867@yongseok-MBP.local> References: <20180310012532.15809-1-yskoh@mellanox.com> <20180402185008.13073-1-yskoh@mellanox.com> <20180402185008.13073-2-yskoh@mellanox.com> <20180403082615.etnr33cuyey7i3u3@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180403082615.etnr33cuyey7i3u3@platinum> User-Agent: Mutt/1.9.3 (2018-01-21) X-Originating-IP: [209.116.155.178] X-ClientProxiedBy: SN4PR0501CA0062.namprd05.prod.outlook.com (2603:10b6:803:41::39) To DB6PR0501MB2039.eurprd05.prod.outlook.com (2603:10a6:4:6::21) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 43d45145-4c18-44b6-369e-08d599c0bbc2 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB6PR0501MB2039; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0501MB2039; 3:ioqMq+omwCNg8ph1asQhzA3yI4zpa1ghtqYZXs5MQs5lpLE5wZ2Wa+1qlMA1lW/4I/hVHBgLsccU0c+sT/+omQUjksVnZhgxM8+2xBJquL0Wuu1R07Wga5QJgqA92Xv4LH4qXlDxbi11HihQtJQG8HIuODRjcS8V1zxACKp3iUQypXzF7j3WmRBHZWW49r84sT8CdLmb14mHDj1qYTplJ4hsD07f2Az+5YbbT+bjX6bdKi+1+80lEdgazLoBCbq3; 25:okeMPGVtvVlNhDxsUy0tgl9cCUXCixxqmPMCqbtVLDp8fAcq7ovufxPhaF64YY7uA4GLuWjKXPLWHm9FeBlkGhv/QgOlkgrAGK+bWE/Mftl7l8yIVbSZ619/XycVVWMqgN+6N6PYMyYS67l0Pve5JG0QUbOwgXbcsYiawqv2tbd7qLgUZUgpAxwisEmGrDQ2RIhd3lEmb00Jj11gu/rlMVWESlUTMnlQAiH2KW1T66Pd1WmpB1NbTk9Iwmj3kwsihD2sC7K2/2EIs8y325+jfZyKSTbHToXx8NdSquDG84LCpC+BHhCO28PSJClnbZAafm+iEAPZHThYKth48X5SHg==; 31:JWbr+NUUJ+fa2r3PHCbfuvyEEnc17OXltGlHNLkgHkmD9pmaiJknB/pAhATJAQcKiQya/UvX84cdU4gkbbX4vwWhTxmzLqnfiCcYJh+tz9n/mD5YX082bAsgfhHFPDLs+M8oZwKml81VfVJl8NAJXwjZUi+X8MiGcUIlu/em9+z2X/LDvffeDHKHaYCtHiayRxs2H5cGSpxM3Xe+EKH5vW4YcaVgVniMFz1sfA8/lHc= X-MS-TrafficTypeDiagnostic: DB6PR0501MB2039: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; DB6PR0501MB2039; 20:SqcaUFFug0I/nldyE+HihHOw5unfVskzx4ZcH6PtXmvWyqMh33MKtCWg97CU6CUkENzyOi6xD/SnuPOXIBdBd5he2ZIOzpfyFfoMw6AXYIhM0L44iSAnxHcWEjWRXL3cFdUn3OVsyE5Xv+VuFoRiROmhNyh51lHfB4WDJA/wfGvdKbynMZjbil0UOSsdGx6YGcd8wTMqXdlHUBof/AH2IkwIKj27PcShkWEuk8WJ0qxyE/vFR+uC82Jd8GkM/64Lrs40b8BmLjdTs5LO2Emyx1qKR0LO+arhx+kpM6pyDHWC+xDWo2k2zmT1hBTrLtZPnp3dARzFXWLM54tTeelMqobJ96tIAux2PRGHEuiBol3gym8Gf8Hgmzukj2qCrXK0dsNKJNeh6ASn395JEgfYYeO0PUxUMEGSh7ksmPvMa8ye4GHVL6BYrdnUyz1OUm174oV5kxF+rd90CEuXYJ8Phc2ukLtT/X6dgLVIvFgV5u1/QRpaEwBfENV0aihxTfcT; 4:E+faI86Qdsav60i9tnRlYiHgOobZpgSqTgxE6pUjBBAzZrpn4uSE7dZzB9pK2pow0dbaH/Ik9KtkQR9QwZJd1cOkpZA+ET3qPo/2O6nijWIWZd1QYJviCy53IFF5vgVFfJ/ivS8PU0vnckF+CdOpoYE+GkcNoi8P+zz6x1kAxyDRZawSdxSeEJWi4zSHK596MAIFK9tt1qHAvUvnRYyIoNAGR15KOeRKuPFE5PThaZpD14u6+Wd9PGkju7zKycdOvyByLcmqAHTnU2vy4mJTzg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB6PR0501MB2039; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0501MB2039; X-Forefront-PRVS: 0632519F33 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(39860400002)(346002)(39380400002)(189003)(199004)(3846002)(1076002)(11346002)(23726003)(386003)(93886005)(86362001)(76176011)(6116002)(2906002)(956004)(52116002)(33896004)(58126008)(16586007)(33656002)(55016002)(316002)(97736004)(6506007)(47776003)(9686003)(25786009)(98436002)(446003)(68736007)(486006)(66066001)(50466002)(6916009)(6666003)(229853002)(476003)(7696005)(8936002)(53936002)(16526019)(81156014)(8676002)(4326008)(5660300001)(106356001)(26005)(186003)(81166006)(5890100001)(305945005)(6246003)(105586002)(478600001)(7736002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0501MB2039; H:yongseok-MBP.local; 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-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB6PR0501MB2039; 23:DnlsGq4NL0MthtLWpYJ6PptGmAIhtRK55IeZ8s/?= =?us-ascii?Q?0Sbzb9TD/zNn6hyOpW3Ke8Ywqwqw53oaPeuqp7Dstj5nAgIZ5OMflG1ABmiP?= =?us-ascii?Q?22kfRYD3QUb9TDQW4FjdgwAM7vnDhSRV6e3b/sRaDCFNAcZ4itb0tg9/1y4U?= =?us-ascii?Q?CXZX3JHaWSV9yNV354V6lQmMt/2G1zZKQWLa+Dx6+v2MoOVrmEYWw2+YTxFg?= =?us-ascii?Q?nhYi8g8Uxu2a+pHOggIt/2+jT2ILv8hxCYuRw7eifw4jEq6I8Qq0tja9Q3cu?= =?us-ascii?Q?l2da1CHqmk4AIYhXcbrMe980FR4DKVsxyxl+D23CrsFJXl95M2I1hl4ANlzK?= =?us-ascii?Q?6DbAqMbsBjdMmQQRTnZGKhgKGnmCLKhowDr1SHLoqIWnwiGFFrZjwNw0gya4?= =?us-ascii?Q?2iXmm2TND7T7h1NB+A3UHAsbmoaxn5MPS6qBly1ey8rTMjbyyZiguYQDHFqR?= =?us-ascii?Q?gHnZIzDVgr4gyAy/Xvt80Ysm7YsTT/mzJQ5eJAoEchUj53GxrveXmvzb5RkO?= =?us-ascii?Q?AqxwrRio2ci4yF8tY/JMRa8nHdZ3jPw08x89eEKvV3JSEkrBXIaDLujiU4w9?= =?us-ascii?Q?F06IedUPGfL55jkXleFbZUbTsARIr4/JJXItnc6v/Y0Onyxi9P/skfXxk9h5?= =?us-ascii?Q?r61IdchHOtIuxbcmsj226qqIbEMl25rDxMaA0wzajCFAUYb6Xfb/M33PPQIc?= =?us-ascii?Q?fzASJ7LlDREPeJTkXlkS6t9+vhM+CBSO7aHYIHImVG7Pi6BiFzfAK81JxxqR?= =?us-ascii?Q?8FbkSjLKJkYMI7xR8rqZ0/WEO3nuUiBm51pk+xpdIrov0WS3PJIq2QUOdV4r?= =?us-ascii?Q?9zYiopVpXdIGkRDdEUzwdm3ssABAn+yWUnd3KUBvVkSTwivCm8QvPqOK4cBE?= =?us-ascii?Q?SSnkZmAtwAFrJ4FROj/awHwRzHnomBziFObgnRJWP/H6X4YS+gxvzrWzU9r9?= =?us-ascii?Q?JQbsKKow3/UNvQvDHJnYo3SVPYFpbVeum97KWaYY4WTrPxO1zDzx61qjN7fs?= =?us-ascii?Q?XK9UFouKzOND7hYa6jwF+/QO7iSmAapasRFUWdXk5y8EkjloKJhUPVEwJJsi?= =?us-ascii?Q?4Ui1swvug4dCObL2OWy+PXn8AKOyCR6V4FC769Fa7MW8EenaNz3BqrgK2nxb?= =?us-ascii?Q?xZsWYYsGC8PLOGLAFuif+URoB9JSMyPIHqMrEJ6rOXmjXVo3Ym0A8QOZLMkU?= =?us-ascii?Q?1IaFkCIzE0Wk5rLHu8sPpUeDxDRoix0fiidZmGyNQZlLEZxIrhHI9M1y7+sI?= =?us-ascii?Q?92PEVDBCGuhyxbT85+DFUC2Evd1oNGEOE8rMXI49QdalBiiyZvQIoe2XJfh1?= =?us-ascii?Q?Hn6QRYEx1Tu0jzwsTXFEU9kMcxe6sGMXjCGMf6w4n1XAh?= X-Microsoft-Antispam-Message-Info: Y2Js0i2wRxi+42AAu0CXUjl4VdKcD7UmxFkKmowhfsq8nm4R2MHYKQTQIL7vQk7sqEuH8JkxiuxW60GwX+QNd7Ve8AGwBuwvuC7LblQ/9SQEjDPONwTCnF2kJIjrPE5z5wFzXUpL1lYOrNcx+RwvW+MGw8x1a558lmhjISMcNvHVdqQE9FShV7WtP1EjPTgz X-Microsoft-Exchange-Diagnostics: 1; DB6PR0501MB2039; 6:AUa4IRXrC9t/a+63dzEQNUQKYVm9YtCZNHlxiy9mej33RY/NGfTXiTXHULh2WOSY54+HoTAeDAJdS6XYR83aMQKl/DGLQmVWcQ3v6UQxxJtSZbjGyOQBKuslvgDvPpiMvp12EwZ9ZyXUxuxIfFQhp6AX0ciM+QS0rboGlsbnxF+xeUnuoQZICcBUqO64OV5y1BKXUra0U0fSdc+DCU8QmptR/c3AeN9BV6ONcwi+5C+4OqYkoQVTJXdCCRoFRIBalSHN1/AGkA7sBxn/GvDU4ZMpyKZj5IT65ZCvzR3IMtANc9bwilKUDo8lfUGEGgbNyy/ZlHX8enAp/klvB2gviuWbjoryDUeDlsnU8QIHhb/ZKYaY/NwPwHbOUehJS/FsP1GmeTvGN4BEBHv7mgwDbd4CoNBmS30BTwyFhELlkjcRlzS2Rnzk6xQPnd407rfPkgWjE9VhucwWKlh0yGE9jg==; 5:IJmOpXnwDLZwSYyikPLy3b1SdmxY0Wt9cACGuNf+LmLC9NkXXWTfO821OWhOLkMvW5rxKfsl+MAs1whiQLUQR7/t9MA5tDj0wXshCivjdDul/tvq9O/CtEIhUOC+kWEksUwHS/2rXfDpAVEt471g62cAx7g2iMUUe8Oi2H8mrss=; 24:49FKXAJqx2QeJfAwWs7N6zMon157uc1GIHgZcFLebX+e22C75VUIwW/Yb+qbV24lpnZtuM1yzFLF+1pAbF3KW8f2qb1qeGjMtVZjLFArX9s= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0501MB2039; 7:ojbFatHzMz9DS58O8gYkxcKpA8sQg9+Qikhowzrp+i4uiicF3lJWOX4+PyVzE9jbejsyAMrd0QzxGDw8Zbe+ml+9EQNDPYgnSkk9o5FMFc96hNSRvrHlG4KnzUu3Vrv/TM/cTqgDqT1g3wSvyOtFDVbaZkOMREjJNjPUuNUwRoiCXmqKAkEc4jVycId7s32+v4isiqJ4TrRjhu12DEUzvJfvM37Bg5rO0MAEwWBsuf5vt9YYGmxiU8udQi3BwZk+ X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2018 00:12:19.2505 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 43d45145-4c18-44b6-369e-08d599c0bbc2 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0501MB2039 Subject: Re: [dpdk-dev] [PATCH v2 1/6] mbuf: add buffer offset field for flexible indirection 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: Wed, 04 Apr 2018 00:12:22 -0000 On Tue, Apr 03, 2018 at 10:26:15AM +0200, Olivier Matz wrote: > Hi, > > On Mon, Apr 02, 2018 at 11:50:03AM -0700, Yongseok Koh wrote: > > When attaching a mbuf, indirect mbuf has to point to start of buffer of > > direct mbuf. By adding buf_off field to rte_mbuf, this becomes more > > flexible. Indirect mbuf can point to any part of direct mbuf by calling > > rte_pktmbuf_attach_at(). > > > > Possible use-cases could be: > > - If a packet has multiple layers of encapsulation, multiple indirect > > buffers can reference different layers of the encapsulated packet. > > - A large direct mbuf can even contain multiple packets in series and > > each packet can be referenced by multiple mbuf indirections. > > > > Signed-off-by: Yongseok Koh > > I think the current API is already able to do what you want. > > 1/ Here is a mbuf m with its data > > off > <--> > len > +----+ <----------> > | | > +-|----v----------------------+ > | | -----------------------| > m | buf | XXXXXXXXXXX || > | -----------------------| > +-----------------------------+ > > > 2/ clone m: > > c = rte_pktmbuf_alloc(pool); > rte_pktmbuf_attach(c, m); > > Note that c has its own offset and length fields. > > > off > <--> > len > +----+ <----------> > | | > +-|----v----------------------+ > | | -----------------------| > m | buf | XXXXXXXXXXX || > | -----------------------| > +------^----------------------+ > | > +----+ > indirect | > +-|---------------------------+ > | | -----------------------| > c | buf | || > | -----------------------| > +-----------------------------+ > > off len > <--><----------> > > > 3/ remove some data from c without changing m > > rte_pktmbuf_adj(c, 10) // at head > rte_pktmbuf_trim(c, 10) // at tail > > > Please let me know if it fits your needs. No, it doesn't. Trimming head and tail with the current APIs removes data and make the space available. Adjusting packet head means giving more headroom, not shifting the buffer itself. If m has two indirect mbufs (c1 and c2) and those are pointing to difference offsets in m, rte_pktmbuf_adj(c1, 10); rte_pktmbuf_adj(c2, 20); then the owner of c2 regard the first (off+20)B as available headroom. If it wants to attach outer header, it will overwrite the headroom even though the owner of c1 is still accessing it. Instead, another mbuf (h1) for the outer header should be linked by h1->next = c2. If c1 and c2 are attached with shifting buffer address by adjusting buf_off, which actually shrink the headroom, this case can be properly handled. And another use-case (this is my actual use-case) is to make a large mbuf have multiple packets in series. AFAIK, this will also be helpful for some FPGA NICs because it transfers multiple packets to a single large buffer to reduce PCIe overhead for small packet traffic like the Multi-Packet Rx of mlx5 does. Otherwise, packets should be memcpy'd to regular mbufs one by one instead of indirect referencing. Does this make sense? Thanks, Yongseok