From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <yskoh@mellanox.com>
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 <dev@dpdk.org>; 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 <yskoh@mellanox.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"adrien.mazarguil@6wind.com" <adrien.mazarguil@6wind.com>,
"nelio.laranjeiro@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: <AM5PR0501MB2033D24C704B7690035B20E1C38F0@AM5PR0501MB2033.eurprd05.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <konstantin.ananyev@intel.com>
> > Cc: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; 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