From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0089.outbound.protection.outlook.com [104.47.1.89]) by dpdk.org (Postfix) with ESMTP id 1AE2CA48F for ; Wed, 25 Apr 2018 20:02:56 +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=jS9fSV97Motgql4GhTbqDZVAv17/n5Hg/o+PM6+/Gy0=; b=McKj1eEawfqNfsqnzcKEx46Y5To/mQU4LEGMvoPulJOW7TjQ7ZC31awtSgM9DgYqigeQTs7VkPdoOR13WEhgfJhkHWzhGBfPfXQ/YX5l+B3kLGSIePoZscXYo6LLeUD6vYI8Goq1M7zbb7R+033VbPUIbUq8mJttDae78+Cg64s= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; Received: from yongseok-MBP.local (209.116.155.178) by AM5PR0501MB2033.eurprd05.prod.outlook.com (2603:10a6:203:1a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.13; Wed, 25 Apr 2018 18:02:49 +0000 Date: Wed, 25 Apr 2018 11:02:36 -0700 From: Yongseok Koh To: "Ananyev, Konstantin" Cc: "Lu, Wenzhuo" , "Wu, Jingjing" , "olivier.matz@6wind.com" , "dev@dpdk.org" , "arybchenko@solarflare.com" , "stephen@networkplumber.org" , "thomas@monjalon.net" , "adrien.mazarguil@6wind.com" , "nelio.laranjeiro@6wind.com" Message-ID: <20180425180235.GD3268@yongseok-MBP.local> References: <20180310012532.15809-1-yskoh@mellanox.com> <20180425025341.10590-1-yskoh@mellanox.com> <2601191342CEEE43887BDE71AB977258AEBCF98C@IRSMSX102.ger.corp.intel.com> <20180425170638.GB3268@yongseok-MBP.local> <2601191342CEEE43887BDE71AB977258AEBCFD59@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB977258AEBCFD59@IRSMSX102.ger.corp.intel.com> User-Agent: Mutt/1.9.3 (2018-01-21) X-Originating-IP: [209.116.155.178] X-ClientProxiedBy: CY4PR13CA0013.namprd13.prod.outlook.com (2603:10b6:903:32::23) To AM5PR0501MB2033.eurprd05.prod.outlook.com (2603:10a6:203:1a::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM5PR0501MB2033; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2033; 3:huMwAuStkS5Py6aq/1Zi3oi39Zepip17Ce/5Vd+cXe1I23MMDizOq11jPNcKBI0TpIIdaVOYLvz9MtPA2JgUXUIW2u4KnDdCmCDfX3jXTtLXX4O6T4SOOHsPKGC8av8A2JJR4K6/tCM5/oQv1uNsU9YNsXl4Q0xvnBAuEV7vyDK3vvAsHJdulVed+59h7QCfMM3E78j+8r/N8jh8pPSBIpTJFXVDMx19CNVzo68eDKrpmyWpLApo8rS0/HEulIgF; 25:cozlKFGq3/yRubt4u37g1YjTY40S7w2yzwbtLeLeX2OKSsJYpoACPDATZOFO4RGHBVx2aO8z4sBTf/Kk4r1BZIgkhV19/Hg0bZ2rVkntx18yu7XcsWSvXXm4VBYOloO3lJzAP3xXdhd0wK9bSvp5UJu3JcfOPGg8W0PSI3Ae28iERkir0KRylKFQ5BzaMl9tnMdX5s06R3a/YCode4/vAHUP4gZ1PVdTG0Eh10VAw6i3tY8S5WkvM4v0f80DY54SD813hZfW7JK5BlMMi9l50MXodU/HIndOnv7RfP7P9w1C04gTK9twh/uJ4wbKu5Q1nXuWVfuddra0ewS0MZmF5A==; 31:yvqBl2/yA2RaS3V6x8ap1L2y+MhrXru/5ANu1i+ClRZi13i+ueuCGQCiJmsTpzQ1dPMPq+m/smfw+zfrv1cmum42bOq8ayVQPI8Ma8L9HjyKJov0jryVr83GuY+K52r2nklfsugTvKd0V2cVGLBTV4nXLaqfzKkso+NeDuDZfUHT1TUnun29wmMQ7g5CJFvAj7ii0I667BlQqPHtj/B+3P7gwfXSuZBdVf1QBeg4t+4= X-MS-TrafficTypeDiagnostic: AM5PR0501MB2033: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2033; 20:tnimIzcGoe51Gmpc6FwPWRi6Lcibnl36usTUZNDmC4RHniXsm71eVlP7DuJ7rAetXh35gXV1iZSL2tvQtySwAQkqAJyhyP8HTIzvX2XaGwSIstSfPk0oKStNF4buzz5M7T3V+7HXoW/FFeKsz4hP8x4hfUWbAQL66liWmGZAqnvO9HDZI2+zmXCIino+2bK9+Kbouusp2hjB71koPA1HM2Atfo71Ufw/4Kdv6t1VTW7RhYqoT+S9W7OUKIctxH+WtzqxH9m0IeD0MmTXzIusrZ9QUVV2jG0TpB1V7hu2qT4ud9/wCIe4qtnHH7DSesh6iR57ld3nWPK/ovj4zf3BsjUlyFnpJYXRWCjuavg0+EPDVGis8XsqFIdTKmUWb3a9vjhGMlgdz0HAS/ROV5kHKSwJrrjC9iY+ZONK2sikKJwWX74M6mAyuBQaj8kw3bXtwz3sJ6cGoSLmIcw4nCPE05E2q0Sg5FITELJaoPubThWTw0EuMVIbJbkOJfC8umVq; 4:VgWYyF9hDLdN4qbPjYH0maj/VOuzi/UroUe7elg7TS9FsPQgLjP/QBZFvkEO/H3iC1U2wqYP9vz6yP7fkdymlVLpctyBCHrNzKN0vFFaaq2AVJ9bGm6P9MrsxY5L7B1N8LVtZ1dNI3mRMcqdtkDryVRpfDhmX27/Odk9BUFfN8gh9d8nbm0aJg5IUDUFZOBtkEKSa4+e7B5rIQyZw13lhSK7Fzx2hxVEAYymHQ4hUl6vLmLC5zvMz+u2k3f5gLZ7IeOB87tuHWeUH+ohU4XusykNW6+KZwJGOTTgCLLJadJ2j38gXBl7IkEqb5OqNe5ft9Y83W8jywnkOK/tlLLtrM67UbmB9yWJld1loc6xXFY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(228905959029699)(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231232)(944501410)(52105095)(6055026)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:AM5PR0501MB2033; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0501MB2033; X-Forefront-PRVS: 06530126A4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(39380400002)(39860400002)(376002)(13464003)(189003)(199004)(81156014)(16586007)(50466002)(5660300001)(16526019)(8936002)(86362001)(105586002)(7696005)(4326008)(93886005)(486006)(6246003)(229853002)(81166006)(25786009)(6916009)(6666003)(33656002)(106356001)(98436002)(478600001)(59450400001)(11346002)(3846002)(66066001)(97736004)(55016002)(2906002)(54906003)(956004)(26005)(305945005)(446003)(5890100001)(68736007)(6116002)(6506007)(8676002)(23726003)(53936002)(58126008)(476003)(186003)(386003)(316002)(52116002)(47776003)(53546011)(76176011)(33896004)(7416002)(1076002)(7736002)(9686003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0501MB2033; 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; AM5PR0501MB2033; 23:Pk+SnBObSPOn+EgfiGhgFPZy2quG3lyGO35LjNj?= =?us-ascii?Q?5Uu83nxE4iGufw66kjBMtY28CnHLzrH0PJ+KsZtT1hEkStoGw6gCaEiRmPAY?= =?us-ascii?Q?XOLznILhmOUQ9uk7CskatkxOaG9MBZk+FcOi7roh3Tp6Nklr8n59fhsA/Sbc?= =?us-ascii?Q?Qnfml3AF5561MJ8uLhmBKNR7TdS6BYLkBFwakH8TakNeWlMH3vGRwTFl3pTN?= =?us-ascii?Q?4SBM9BiVTvfj3k+bGubJXOdUeN35aXs3kOSKswx+w1sA2M6Ceg0w/ExQheWt?= =?us-ascii?Q?tNNz+GbYg/fgjKlBZyYfEJK2pup9mdITxzREY/K+bC5QSbMhYq7/nwJXKYa0?= =?us-ascii?Q?AlAFGfYgJ7jqfc1Wy1Y5cXdwlUe0k6XzKFBIH7X65s/mTd31zfNRUk7dAWTU?= =?us-ascii?Q?kAonlY9RcM2vk/VQProGj4hFDJOvszQwoMy6D/z98K2tzmdcrTGqjtoVpy/w?= =?us-ascii?Q?bW7AQ5iZLq8jDZ45o/Dz+36bs8kyUsF65+FA4OxKGByN5Knfn37CYB9T/1yf?= =?us-ascii?Q?Tl6WJF649/WgP8tCTH7zmwsP7f8fgxMTERd5lco2pGPYw0S0cl1iFdxzOMhF?= =?us-ascii?Q?QiBwGmyD6dWqPaRuuUDe78LorKHMoLeFwKqVmAHPrHL1GXUNMGX40zezT62I?= =?us-ascii?Q?y9lJ5FOBh6tQ6bxzLB89AOp9xmuvilAZbGIjOiUGs8u7RIMp8886fe/W8uOL?= =?us-ascii?Q?p+Q2IRCUV+XxfDJvng1fhsoCMN/nF5tuxbhRj+1mb75/TnVxtT9/W1Mc1S3H?= =?us-ascii?Q?CgGSbzaw16svDL6y7B3fRXy3zOWE36rX5jp8ptnzORiCf+SsVGwVrLbiV+dm?= =?us-ascii?Q?aBW0KJyjVCggAsfNJsyNXcrmi8TW0+0m9OEciNGaEDOiuFppxBrWxjDkSx3b?= =?us-ascii?Q?ayJxpbMc6KS5DCF3AtaKrs0SW/5ISUFPCuWl3kDMjXdOfkF7o1Ha5M1ufqGo?= =?us-ascii?Q?2jHE7Drh3Lk+5BMCPaIiGiG+4ccGTtDXYnkYb+1EX4B6gsciml3YoC9HHICm?= =?us-ascii?Q?+qmxW9y3PYvnIvvcrcxoSGFmmbFYW9UVk6IUZKi0JqTWWdDiswlZp2h+9RM4?= =?us-ascii?Q?+n/hsROBXe1vIL4kRubwpbUTALaSjC7CHBFQvcMTr9Rdzj22pacTesDb1cQM?= =?us-ascii?Q?baaoDSsrwDLWJzBEwYB4deUZs9bdfPEuewcpbyq/TPAQETq1QTeckz+ebOj8?= =?us-ascii?Q?ffnSX6AQkI4w2qEvbGn5xjbTzbivLVTtZl9TiudrjyLLPuuBzkulvinfdNh2?= =?us-ascii?Q?rS0/9WhnhWSmyT6inP9KbQLRO/TIgbCZnTeycT2dzLfOCIP2pAV4SFo4oMPa?= =?us-ascii?Q?I04OTQUyidleqbKST7L1HeyS6u3RglIgRFbov0VCqBpxpHfHsp0Jed1YW7Xw?= =?us-ascii?Q?4Fx+5or3BmKdTeNqC5pYcX4RYzuCjZIJbJ8x5chC37cxs6I9mFEV857cHibs?= =?us-ascii?Q?0RPZic4gnVvwd7KH9bTIQgO+1LFXyRao=3D?= X-Microsoft-Antispam-Message-Info: UAW+FbPHMVvEVQ8gJu3m/y0i+QD4mTm8okj3vr3A1n7eRtnbmPKLqdz9PPOevDo30Lztp2sFtykJBMoGyAqSxyzADW3FkkM6lklOB0wEX/txU8EIq6inbvv6xZ3LtRLsa5vhrqUlOduJqcaKZvEWHNpJN2WsyZLY2NBR9dSu1S6VPCFOfZPBgLcaN8sQ0QR+ X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2033; 6:bMdL98y1wlq4xMIkMziafFCGvtwUk5enM8oiDcxp0rgS6ep1x+gQCLXVcAuYeQDAJqIvJw35Qj+2jn+Q2jHCFjsN8+uXqOrmkuVuTFBe6Y+YfZCEQUArn1dmYhxU555ZZhVSzKr5MZP80Q+yYCN/SzCWomZGl/zJctGuEJCoD+PCCKhFG91oEvPYpFO1FOVDNaPDX++HzjIEFt/MqJ+PGGwzs+E/3ELJVp+V7R7vWgL5pHCoepr2EnbC2SAq7BEQuVmhA6SZQYWrxU6CUAUtgQgrtsTFqCuw4QKqwgO85OzYMRIst6NivDdt/RL1S2+E/lyVMPZJ9cfFlxgDSb366EmgXzXyzidzwgevOYZkZwFCu8dAVHewXENQXoJ6dL8nnfDGcjNiJ7wUQeO3nUXvb9MOVhFOB48Yx+0HM34XOVkP0BmNaaLjAc5Yqj7rHjBZ+Dn7CghWLN8fcAbNqYouLA==; 5:qKmQSgrUwY1g7re8IzXvJqyY26HrNwo/MZG8p8gzhb5spzhRTxyLZxpWkwWUpBRHgSL4dlyIT9f+slMidkBrXjTwi9GiEM/94cCjP5MIvfo8zki88UMUG6jCOGuNP80LqDfB5+YkuTw3EaO11jRWO0mHdmWLXBEJ8mxkUWzFO7c=; 24:X1ABjLTWcFmQ/LsXF7LojmSGUp2K8gCdHmUzKtUiVO03uo63ShlmE3U0cAXFgcbV/ZtlTt4Zcp6M4PKeIblaA8DLC+7BOJlYGw9FQhzCfWg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2033; 7:Lncok8I8Jk2xoxgXzfYuJbbcHz2O+0lZ0n5ykSOg1Q2YhdWmwlEhhnShon/re8b8K30EBKARI+56SmRqK1nmWoJD83i1PkL4SZVcKjkWzbh7/ghT6Dn6Fmz2jIKlZ4a598giiLf44MbBkD8wKojVGqYKG8Mk3zvBGZhFnvziZlUcuZLdpohjWeNmLXJS1fnRug3j/PwJLwCIKksGbBft4yvsFZCdRIhEWMgfYifJX5JtX2bRYR+YSLTE5nBsDRaJ X-MS-Office365-Filtering-Correlation-Id: 8d36e493-5579-4aeb-5a41-08d5aad6c34c X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2018 18:02:49.9857 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8d36e493-5579-4aeb-5a41-08d5aad6c34c X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0501MB2033 Subject: Re: [dpdk-dev] [PATCH v5 1/2] mbuf: support attaching external buffer to mbuf 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, 25 Apr 2018 18:02:56 -0000 On Wed, Apr 25, 2018 at 05:23:20PM +0000, Ananyev, Konstantin wrote: > > > > -----Original Message----- > > From: Yongseok Koh [mailto:yskoh@mellanox.com] > > Sent: Wednesday, April 25, 2018 6:07 PM > > To: Ananyev, Konstantin > > Cc: Lu, Wenzhuo ; Wu, Jingjing ; olivier.matz@6wind.com; dev@dpdk.org; > > arybchenko@solarflare.com; stephen@networkplumber.org; thomas@monjalon.net; adrien.mazarguil@6wind.com; > > nelio.laranjeiro@6wind.com > > Subject: Re: [PATCH v5 1/2] mbuf: support attaching external buffer to mbuf > > > > On Wed, Apr 25, 2018 at 01:31:42PM +0000, Ananyev, Konstantin wrote: > > [...] > > > > /** Mbuf prefetch */ > > > > #define RTE_MBUF_PREFETCH_TO_FREE(m) do { \ > > > > if ((m) != NULL) \ > > > > @@ -1213,11 +1306,127 @@ static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool, > > > > } > > > > > > > > /** > > > > + * Attach an external buffer to a mbuf. > > > > + * > > > > + * User-managed anonymous buffer can be attached to an mbuf. When attaching > > > > + * it, corresponding free callback function and its argument should be > > > > + * provided. This callback function will be called once all the mbufs are > > > > + * detached from the buffer. > > > > + * > > > > + * The headroom for the attaching mbuf will be set to zero and this can be > > > > + * properly adjusted after attachment. For example, ``rte_pktmbuf_adj()`` > > > > + * or ``rte_pktmbuf_reset_headroom()`` can be used. > > > > + * > > > > + * More mbufs can be attached to the same external buffer by > > > > + * ``rte_pktmbuf_attach()`` once the external buffer has been attached by > > > > + * this API. > > > > + * > > > > + * Detachment can be done by either ``rte_pktmbuf_detach_extbuf()`` or > > > > + * ``rte_pktmbuf_detach()``. > > > > + * > > > > + * Attaching an external buffer is quite similar to mbuf indirection in > > > > + * replacing buffer addresses and length of a mbuf, but a few differences: > > > > + * - When an indirect mbuf is attached, refcnt of the direct mbuf would be > > > > + * 2 as long as the direct mbuf itself isn't freed after the attachment. > > > > + * In such cases, the buffer area of a direct mbuf must be read-only. But > > > > + * external buffer has its own refcnt and it starts from 1. Unless > > > > + * multiple mbufs are attached to a mbuf having an external buffer, the > > > > + * external buffer is writable. > > > > + * - There's no need to allocate buffer from a mempool. Any buffer can be > > > > + * attached with appropriate free callback and its IO address. > > > > + * - Smaller metadata is required to maintain shared data such as refcnt. > > > > + * > > > > + * @warning > > > > + * @b EXPERIMENTAL: This API may change without prior notice. > > > > + * Once external buffer is enabled by allowing experimental API, > > > > + * ``RTE_MBUF_DIRECT()`` and ``RTE_MBUF_INDIRECT()`` are no longer > > > > + * exclusive. A mbuf can be considered direct if it is neither indirect nor > > > > + * having external buffer. > > > > + * > > > > + * @param m > > > > + * The pointer to the mbuf. > > > > + * @param buf_addr > > > > + * The pointer to the external buffer we're attaching to. > > > > + * @param buf_iova > > > > + * IO address of the external buffer we're attaching to. > > > > + * @param buf_len > > > > + * The size of the external buffer we're attaching to. If memory for > > > > + * shared data is not provided, buf_len must be larger than the size of > > > > + * ``struct rte_mbuf_ext_shared_info`` and padding for alignment. If not > > > > + * enough, this function will return NULL. > > > > + * @param shinfo > > > > + * User-provided memory for shared data. If NULL, a few bytes in the > > > > + * trailer of the provided buffer will be dedicated for shared data and > > > > + * the shared data will be properly initialized. Otherwise, user must > > > > + * initialize the content except for free callback and its argument. The > > > > + * pointer of shared data will be stored in m->shinfo. > > > > + * @param free_cb > > > > + * Free callback function to call when the external buffer needs to be > > > > + * freed. > > > > + * @param fcb_opaque > > > > + * Argument for the free callback function. > > > > + * > > > > + * @return > > > > + * A pointer to the new start of the data on success, return NULL > > > > + * otherwise. > > > > + */ > > > > +static inline char * __rte_experimental > > > > +rte_pktmbuf_attach_extbuf(struct rte_mbuf *m, void *buf_addr, > > > > + rte_iova_t buf_iova, uint16_t buf_len, > > > > + struct rte_mbuf_ext_shared_info *shinfo, > > > > + rte_mbuf_extbuf_free_callback_t free_cb, void *fcb_opaque) > > > > +{ > > > > + /* Additional attachment should be done by rte_pktmbuf_attach() */ > > > > + RTE_ASSERT(!RTE_MBUF_HAS_EXTBUF(m)); > > > > > > Shouldn't we have here something like: > > > RTE_ASSERT(RTE_MBUF_DIRECT(m) && rte_mbuf_refcnt_read(m) == 1); > > > ? > > > > Right. That's better. Attaching mbuf should be direct and writable. > > > > > > + > > > > + m->buf_addr = buf_addr; > > > > + m->buf_iova = buf_iova; > > > > + > > > > + if (shinfo == NULL) { > > > > > > Instead of allocating shinfo ourselves - wound's it be better to rely > > > on caller always allocating afeeling it for us (he can do that at the end/start of buffer, > > > or whenever he likes to. > > > > It is just for convenience. For some users, external attachment could be > > occasional and casual, e.g. punt control traffic from kernel/hv. For such > > non-serious cases, it is good to provide this small utility. > > For such users that small utility could be a separate function then: > shinfo_inside_buf() or so. I like this idea! As this is an inline function and can be called in a datapath, shorter code is better if it isn't expected to be used frequently. Will take this idea for the new version. Thanks. > > > Again in that case - caller can provide one shinfo to several mbufs (with different buf_addrs) > > > and would know for sure that free_cb wouldn't be overwritten by mistake. > > > I.E. mbuf code will only update refcnt inside shinfo. > > > > I think you missed the discussion with other people yesterday. This change is > > exactly for that purpose. Like I documented above, if this API is called with > > shinfo being provided, it will use the user-provided shinfo instead of sparing a > > few byte in the trailer and won't touch the shinfo. > > As I can see your current code always update free_cb and fcb_opaque. > Which is kind of strange these fields shold be the same for all instances of the shinfo. > > > This code block happens only > > if user doesn't provide memory for shared data (shinfo is NULL). > > > > > > + void *buf_end = RTE_PTR_ADD(buf_addr, buf_len); > > > > + > > > > + shinfo = RTE_PTR_ALIGN_FLOOR(RTE_PTR_SUB(buf_end, > > > > + sizeof(*shinfo)), sizeof(uintptr_t)); > > > > + if ((void *)shinfo <= buf_addr) > > > > + return NULL; > > > > + > > > > + m->buf_len = RTE_PTR_DIFF(shinfo, buf_addr); > > > > + rte_mbuf_ext_refcnt_set(shinfo, 1); > > > > + } else { > > > > + m->buf_len = buf_len; > > > > > > I think you need to update shinfo>refcnt here too. > > > > Like explained above, if shinfo is provided, it doesn't alter anything except > > for callbacks and its arg. > > Hm, but I have 2mbufs attached to the same external buffer via same shinfo, > shouldn't shinfo.refcnt == 2? If the shinfo is provided by user, user is responsible for managing the content. Please refer to my reply to Andrew. I drew a few diagrams. Thanks, Yongseok