From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0043.outbound.protection.outlook.com [104.47.2.43]) by dpdk.org (Postfix) with ESMTP id 01CC5E5D for ; Tue, 24 Apr 2018 03:30:18 +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=D3BAAkb1/Bu/69s4omcC+A2rsajd4FjADWZtbpLKzVA=; b=qpnGKAnZSrJ4+VkBUE9shFWUBqqbTODj7xELHW62PGA/Km/GD6tsXq5I+Zv07Rv/mvgTf+JNbloq6zK/I3mftyf05krSUzSqlxLOQNMFXMKVu2B1BVaNTiQfmf6r9bdSYVcHYsGBrbO7YnJIjUEUEnsX8RIiIlbDgYPaD765PEI= Authentication-Results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=mellanox.com; Received: from yongseok-MBP.local (209.116.155.178) by VI1PR0501MB2046.eurprd05.prod.outlook.com (2603:10a6:800:36::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.15; Tue, 24 Apr 2018 01:30:12 +0000 Date: Mon, 23 Apr 2018 18:29:57 -0700 From: Yongseok Koh To: Olivier Matz Cc: wenzhuo.lu@intel.com, jingjing.wu@intel.com, dev@dpdk.org, konstantin.ananyev@intel.com, adrien.mazarguil@6wind.com, nelio.laranjeiro@6wind.com Message-ID: <20180424012948.GA81551@yongseok-MBP.local> References: <20180310012532.15809-1-yskoh@mellanox.com> <20180419011105.9694-1-yskoh@mellanox.com> <20180423161843.tg2b23cl7ewoflj3@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180423161843.tg2b23cl7ewoflj3@platinum> User-Agent: Mutt/1.9.3 (2018-01-21) X-Originating-IP: [209.116.155.178] X-ClientProxiedBy: DM3PR12CA0045.namprd12.prod.outlook.com (2603:10b6:0:56::13) To VI1PR0501MB2046.eurprd05.prod.outlook.com (2603:10a6:800:36::20) 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:VI1PR0501MB2046; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2046; 3:AIX3YIWrCSGIFtsFcEXINOLFjVy8ZNHQh18MRN6ivQTCPGMb/vw6i+4EVKz4KXftlrVCxBOizUROuIm0+wZpC8H0R1JNu1qBP4UzDtZF+bW6ZKjAMGj7yI3d+mmLRnQhhK4RE1EwteJ5WkupEqp1ef+WDPmHUgVebybt6Bm6SoH2MylWcUlWFGUu4WpqKH8CgqUqezgWCYm1pbbwhUoRRqhyClVoMv1AqKdkTfQJTqzfnHBh0R/G0Wt/LRzzIEzj; 25:/hvGJXxglNSNhlCiII5ZRmbyLJGA/2z9PLHIPp+MfxovLFcbAewEm6QfG1Cq8giY3BYNpqypN4n1dbHeP1kKHirIWp5Skk1q1/XX9E2CL7G7q74cBLb15R5r1wHfw4GtFP4zdUNpeJkWND+8d14NLf/+pohnVaIbn1iFX5TmMmZvOZ2tA7KypGRlpSh39+/p74eWFlX3Q1nZ9cfAfCd1KukkqevTsjvWzZ4whBYW8/XyUQGVrVIUHfche1zcI3KhJYmkQ6lgE6kWtiXWwAVrQ5799/28TatgtlSEJSFy9IjOI4dkbVePqotwaU5i7ce90GAHvE7XT+QDwgffzx5X6g==; 31:+O0dSNPNy3TzBYk2WYgbqil2sf6TyDev+q6jhjPu9X69YCEQ1H1BWyFAbvSZAoI8VSEu/jLkcIZAnag7BuKb3Im10v0skK+bCh5VbldHyMfdJ4HwTa44dpQ7JoAJ0VFmtp9ZiezPq/iiUZfk8PxSGD9VUcpW9nbEDASEG74XZUcva5RWGjhh0UJUiBFFAhJpw4vkPigCHzOiNEkAnJe5quPvw7MVrRb6fhM3jB9sPfM= X-MS-TrafficTypeDiagnostic: VI1PR0501MB2046: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2046; 20:/cDrfSna5tMdHsXiPI3BHtUERmF63FQxG6P9q/9iNRxpDqng4f+p0YKOjEx7hMwSsW233Au0Ibz7w6VujMbred3K2B/P5U6/Igx3x1lKrHa2NK04NZU7v/ZFf3wY9pZI41umqOzAUGWvQKb+Ur+KX/XuIL3EkkMS3C8IOYuuz2WbAmnbdZYTTkFuXK9PQ5inf5V9YpF0p61flUPX+vcrFRgD9h/+81RHZS6Fj7YilHr4j3N3LaLlHe3EFytoenRbZRxby1D+WprX0JO8/pNka434H+VM8ffMdAFkCm21NEHeIEkg0ku4LHKUvv5Ohlb1EG8ptwE7UIjK6e4NIf0I8JfPCJhFKKlIQx/7R4aixJbva3+gE/3FgE2pJshoaIW8ecT49FAZehBK/kkANMdc70k/6uQizgo0UCugzkcL18LCyNRh9lZJm3EcM11/lbYhk+voKRI0rpfyqJ0zKr3e7bqVXbxj6EyVr4T/UhEm19vR3+24oppl2XnCh9jldjub; 4:hI4nnzvmtn3B8MUTdGkTzYnUS0klmec5O1G5eszN7ssyPV5xjbP58yebziBBmDqCl5NdumSwFGH/az9XCErieyBCTxsSTXJtSAFEiXXV1Ep1MZ1ea3rYdTrkHaBga8fKVeEN+4COuVkH1/ufKE6ST0ZLuaXbSmKPn/mUg2iM2SSuAsxzjBzW/BUsbGB5O6zSpBfZZPnP0jb4puKJRNSmWX2jyGkNYWysBmyQcM9Mr03vMObflLAKuOQHI0nMvLNde5Flf4hybzPiEhLerCcC3TerB+nOZFQHkLUM+cnt7tdQVDWiZZ95LHPXq9yka/3B X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231232)(944501410)(52105095)(6055026)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0501MB2046; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0501MB2046; X-Forefront-PRVS: 0652EA5565 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(366004)(396003)(39860400002)(376002)(5890100001)(6916009)(6666003)(11346002)(47776003)(956004)(66066001)(476003)(9686003)(446003)(6246003)(2906002)(229853002)(478600001)(16526019)(186003)(26005)(386003)(6506007)(59450400001)(7696005)(76176011)(52116002)(50466002)(33896004)(8676002)(3846002)(6116002)(23726003)(8936002)(1076002)(4326008)(98436002)(305945005)(316002)(33656002)(16586007)(7736002)(55016002)(53936002)(81166006)(86362001)(25786009)(5660300001)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0501MB2046; H:yongseok-MBP.local; FPR:; SPF:None; LANG:en; MLV:sfv; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR0501MB2046; 23:Gc322Xr1I51QFccwte8lfTU82036FdDKFuPN2I0?= =?us-ascii?Q?719ubtwMvUTN6hgnBkebDwAyH78VD3i7t25qA3aLgaKD/g54mhMMYzdM6YHW?= =?us-ascii?Q?O/HgH44Yh2YdfSegGIgnk1ALgxV5TwV8nvHTFW9qwcjprXrzQhuXox6SzQuk?= =?us-ascii?Q?fKmGgQx3yvJTAJlpFV2V6PfNsJmu/MZUgBsoUp4AqNPlSLoES8q7248UsjZ/?= =?us-ascii?Q?ArQN2Wwz8HdXIYXvaM3HgvRnV/hvFWff6CEYbJdliczQoJyj4rza9pBG8fyi?= =?us-ascii?Q?HDrKN7dL5tBvuEkDOIvCE62r5Ty03GPyGgYzC1r8aLaBbcx4hVDXE+QF0EC1?= =?us-ascii?Q?lM6bXv53BWfZyU0iAZqltwTYiZ17Mcio4yXkkHtbLB0uhiseMqcJvY/nHqsJ?= =?us-ascii?Q?1VgO+qShRJ9DM6vQrkL2vC4EvP8zu+7GVZs+2FA2QBxuja0EPe7KZXuk81xS?= =?us-ascii?Q?IOefY5TdnlKY5mIlY2wUf/EGItGr8P/4OjMt9mfAReVSjOi/ByCBXu8M7etG?= =?us-ascii?Q?ANea7l3319ujm8B13bLyPBUxA5ezLQ8NwGAso6TQ/8iXTxWlOqlkDW4k/wdY?= =?us-ascii?Q?GqzYQRjun2ozHXCrU3LMET19wdLaIEDN1iUaPxce9DisG/N344IyzUvDC8oU?= =?us-ascii?Q?l51jVxSNCmACo9/wYM0CctcjBoBda0LY5Tmkp8FbXXgwq5VBxPphgDZDPmTu?= =?us-ascii?Q?9ZjbwMCZfXwhIwgyBt3uOGt1OFyGEjAoJfEZh2I79CZiE+gtFdq//o23jy6s?= =?us-ascii?Q?JQXuBpkEGsDYpmh91oqNQB1Efj9Bo8hY+gzHEZl+n+lnsXs2IID4HkywR08I?= =?us-ascii?Q?Qgq1JY91acO9krSvjT5eZAIbsWsLxCQcWf/rWZSGEne503+mTyJp5YYtGo/k?= =?us-ascii?Q?xgxSTiiMcBOCt9YpvmdO7Bbesz00/ZH1rVG01j1KJxFL8PO8Eo2ihnfTLUjy?= =?us-ascii?Q?3zRYZHgRozvMmqM386Rf5Hi9MQtdJTVr7QdZEdcg4AuKT1EmEGNLj2p2VbCX?= =?us-ascii?Q?CBccyFhrFFIsWcixyEszSavFgAT+hDSzIjB6Iy1YizDYOkZTgCBZxEldqDRt?= =?us-ascii?Q?vhpLEsjZi1JEPdrkwl0YOLHQurqoRT2v9doDuFqUcibBzxWjBVCKmixThqJr?= =?us-ascii?Q?mJpx7rRaqucq42MJcQX9yaLmoOtCConsoZKkTp3awXHMgyGw/7nE8iA=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Antispam-Message-Info: YUlSvKXXX38J0zsXI8g0L7wFung/6bRf+F5cS906R6d+jdQmt23vSV/D74SDzOK8QbDNZjbLGLpJMH5xo2kbv6QySGAJ9Kj0twAQjSbvObF9ppflWlDKrL1YpoLIc3JptDxeIumFoJQk4wD98czoWEyXcMkiQ7KcWIjf6l9OVbKbDubY97wgWIbzPbyaeEd0 X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2046; 6:WUEJMAdJSUzWRHGOWr0Q+Y6gXuEVCgcKWjX/ej2S6HFngUZjBswKA7Oe7pkwYcbqkQpWTU1r/NCiMpN7hz7jb3eGi5Xb5w3oKBlo7i7hnzeTzENQQfrW8dsW1nZwfbntCkDUtMpb68AuZTCNPerqaN2+IXKcunw4CDalIWXLPPDstF45auhifNcm2mGKFRLTNyLuRJNkERjF1y2wnEon1RHUrtvRETn/Vr8jKZdqP5YAyuA6qspw4okPGvqUeOwzftShHHVjXZTDwhd407FMUPZ7O+6dYxhGmaV5tniEuRt6P4ixGQCIN4QISNDds1f04HPgsfjbKrla3SavfFJfyK4uvrBAmLtOUuAGqm9kLFw1nzWoOHxp9Ym0nOv2DQ8B7tN9iYiSypjaNpkM/pk3D+Gx4riwa/GRj72YGGwDqWvDEpdBjLeWHEdMYBzGEH32fTgp3hQZHf3uEIMW9ZcAEA==; 5:wgJxXQzSD3dd7dqR9OOGXC5OC+6jZgVzyHXQnEj1fpmsErdpimQD9YR4Wl61bCCFWVbtAwlsB8FvLpwo3a9iPcErZ8IHe1sthDgOpAr+f9nDCL7dGKsXl/FuKDCOshYhLowd8J2dPTtlwwAHp8AG+x2tDnGn4mG905SXVTXJRLQ=; 24:rYyr+xamzIb5zuBCOCbsX1+fr02xicJVAAcSh5DIRqVukPWtRM8tIQQnwJlUnMTWIiIxo/G2vZl/2LXm/tQZgP9G/jglPtjzeh1FqQcQGWE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2046; 7:th6eW6Cnd0IHrRApWi4TXYHAiV7J95tpvuS+iYp2eJ56bRqjsx4qlzfTrGgNFjCxtTT22iehRifoll3LH2zZbMU0xcxilEenCKCFfgmjnvbIHhdmtg+y4VpCn4RyhZyzKoA5qH4vUBpuX2jN10oP0RXv1620I9u3MyVWEWxu17EbZRSqAbnKVTI94CeDVeh+Kl6oeGEVzg8KmDc3Uv/D9VZGc0U6k0h6qPuyC93LG96qQng43LTTRYRzdgFSAC9+ X-MS-Office365-Filtering-Correlation-Id: 4503fa88-0745-4e6c-362c-08d5a982ed93 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2018 01:30:12.4014 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4503fa88-0745-4e6c-362c-08d5a982ed93 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0501MB2046 Subject: Re: [dpdk-dev] [PATCH v3 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: Tue, 24 Apr 2018 01:30:19 -0000 On Mon, Apr 23, 2018 at 06:18:43PM +0200, Olivier Matz wrote: > Hi Yongseok, > > Please see some comments below. > > On Wed, Apr 18, 2018 at 06:11:04PM -0700, Yongseok Koh wrote: > > This patch introduces a new way of attaching an external buffer to a mbuf. > > > > Attaching an external buffer is quite similar to mbuf indirection in > > replacing buffer addresses and length of a mbuf, but a few differences: > > - As refcnt of a direct mbuf is at least 2, 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. > > I'm wondering if "As refcnt of a direct mbuf is at least 2" should be > clarified. I guess we are talking about a direct mbuf that has another one > attached too. > > I'm also not sure if I understand properly: to me, it is possible to have > an indirect mbuf that references a direct mbuf with a refcount of 1: > m = rte_pktmbuf_alloc() > mi = rte_pktmbuf_alloc() > rte_pktmbuf_attach(mi, m) > rte_pktmbuf_free(m) Totally agree. Will change the comment. [...] > > +struct rte_mbuf_ext_shared_info { > > + rte_mbuf_extbuf_free_callback_t free_cb; /**< Free callback function */ > > + void *fcb_opaque; /**< Free callback argument */ > > + RTE_STD_C11 > > + union { > > + rte_atomic16_t refcnt_atomic; /**< Atomically accessed refcnt */ > > + uint16_t refcnt; /**< Non-atomically accessed refcnt */ > > It looks that only refcnt_atomic is used. > I don't know if we really need the non-atomic one yet. Will remove. > > + }; > > +}; > > + > > /**< Maximum number of nb_segs allowed. */ > > #define RTE_MBUF_MAX_NB_SEGS UINT16_MAX > > > > @@ -693,9 +711,14 @@ rte_mbuf_to_baddr(struct rte_mbuf *md) > > #define RTE_MBUF_INDIRECT(mb) ((mb)->ol_flags & IND_ATTACHED_MBUF) > > > > /** > > + * Returns TRUE if given mbuf has external buffer, or FALSE otherwise. > > + */ > > +#define RTE_MBUF_HAS_EXTBUF(mb) ((mb)->ol_flags & EXT_ATTACHED_MBUF) > > + > > +/** > > * Returns TRUE if given mbuf is direct, or FALSE otherwise. > > */ > > -#define RTE_MBUF_DIRECT(mb) (!RTE_MBUF_INDIRECT(mb)) > > +#define RTE_MBUF_DIRECT(mb) (!RTE_MBUF_INDIRECT(mb) && !RTE_MBUF_HAS_EXTBUF(mb)) > > I'm a bit reticent to have RTE_MBUF_DIRECT(m) different of > !RTE_MBUF_INDIRECT(m), I feel it's not very natural. > > What about: > - direct = embeds its own data > - clone (or another name) = data is another mbuf > - extbuf = data is in an external buffer Good point. I'll clarify it in a new version by adding RTE_MBUF_CLONED(). > > /** > > * Private data in case of pktmbuf pool. > > @@ -821,6 +844,58 @@ rte_mbuf_refcnt_set(struct rte_mbuf *m, uint16_t new_value) > > > > #endif /* RTE_MBUF_REFCNT_ATOMIC */ > > > > +/** > > + * Reads the refcnt of an external buffer. > > + * > > + * @param shinfo > > + * Shared data of the external buffer. > > + * @return > > + * Reference count number. > > + */ > > +static inline uint16_t > > +rte_extbuf_refcnt_read(const struct rte_mbuf_ext_shared_info *shinfo) > > What do you think about rte_mbuf_ext_refcnt_read() to keep name consistency? > (same for other functions below) No problem. > [...] > > > @@ -1195,11 +1270,120 @@ static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool, > > } > > > > /** > > + * Return shared data of external buffer of a mbuf. > > + * > > + * @param m > > + * The pointer to the mbuf. > > + * @return > > + * The address of the shared data. > > + */ > > +static inline struct rte_mbuf_ext_shared_info * > > +rte_mbuf_ext_shinfo(struct rte_mbuf *m) > > +{ > > + return (struct rte_mbuf_ext_shared_info *) > > + RTE_PTR_ADD(m->buf_addr, m->buf_len); > > +} > > This forces to have the shared data at the end of the buffer. Is it > always possible? I think there are use-cases where the user may want to > specify another location for it. > > For instance, an application mmaps a big file (locked in memory), and > wants to send mbufs pointing to this data without doing any copy. Very good point. Will make rte_pktmbuf_attach_extbuf() take *shinfo as an argument. > Maybe adding a m->shinfo field would be a better choice, what do you > think? I like it to store in mbuf too. > This would certainly break the ABI, but I wonder if that patch does > not already break it. I mean, how would react an application compiled > for 18.02 if an EXTBUF is passed to it, knowing that many functions > are inline? Even if I add shinfo field in rte_mbuf, I think it won't break the ABI. The second cacheline is just 40B and it would simply make it 48B. Some code might check the order/size of some fields (e.g. vPMD) in the struct, but if it is added at the end of the struct, it should be okay. And there's no need to make a change in a C file for this. > > +/** > > + * 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. > > + * > > + * 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()``. > > + * > > + * A few bytes in the trailer of the provided buffer will be dedicated for > > + * shared data (``struct rte_mbuf_ext_shared_info``) to store refcnt, > > + * callback function and so on. The shared data can be referenced by > > + * ``rte_mbuf_ext_shinfo()`` > > + * > > + * Attaching an external buffer is quite similar to mbuf indirection in > > + * replacing buffer addresses and length of a mbuf, but a few differences: > > + * - As refcnt of a direct mbuf is at least 2, 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. > > + * - 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 consiered direct if it is neither indirect nor > > small typo: > consiered -> considered Will fix. Thanks. > > + * 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_len > > + * The size of the external buffer we're attaching to. This 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 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, > > + uint16_t buf_len, rte_mbuf_extbuf_free_callback_t free_cb, > > + void *fcb_opaque) > > +{ > > + void *buf_end = RTE_PTR_ADD(buf_addr, buf_len); > > + struct rte_mbuf_ext_shared_info *shinfo; > > + > > + shinfo = RTE_PTR_ALIGN_FLOOR(RTE_PTR_SUB(buf_end, sizeof(*shinfo)), > > + sizeof(uintptr_t)); > > + > > + if ((void *)shinfo <= buf_addr) > > + return NULL; > > + > > + m->buf_addr = buf_addr; > > + m->buf_iova = rte_mempool_virt2iova(buf_addr); > > Agree with Konstantin's comment. I think buf_iova should be an argument > of the function. Oops, that was my silly mistake. I just copied this block from rte_pktmbuf_init(). Then, I wanted to change it to rte_malloc_virt2iova() but I forgot. I didn't realized it during my tests because mlx devices don't use iova but virtaddr. If it takes iova as an argument instead, it can be faster and it can use 'real' external memory for packet DMA, e.g. storage application you mentioned. I mean, even if a buffer isn't allocated inside DPDK (doesn't belong to one of memseg list), this should work. Good suggestion! > > + m->buf_len = RTE_PTR_DIFF(shinfo, buf_addr); > > Related to what I said above: I think m->buf_len should be set to > the buf_len argument, so a user can point to existing read-only > data. I will make a change to have an argument of extra memory for shared data. And if shinfo is passed as NULL, it will still spare bytes at the end, just for convenience. > [...] > > Few more comments: > > I think we still need to find a good way to advertise to the users > if a mbuf is writable or readable. Today, the rules are quite implicit. > There are surely some use cases where the mbuf is indirect but with > only one active user, meaning it could be READ-WRITE. We could target > 18.08 for this. Right. That'll be very good to have. > One side question about your implementation in mlx. I guess the > hardware will write the mbuf data in a big contiguous buffer like > this: > > +-------+--------------+--------+--------------+--------+- - - > | |mbuf1 data | |mbuf2 data | | > | | | | | | > +-------+--------------+--------+--------------+--------+- - - > > Which will be transformed in: > > +--+----+--------------+---+----+--------------+---+---+- - - > | |head|mbuf1 data |sh |head|mbuf2 data |sh | | > | |room| |inf|room| |inf| | > +--+----+--------------+---+----+--------------+---+---+- - - > > So, there is one shinfo (i.e one refcount) for each mbuf. > How do you know when the big buffer is not used anymore? +--+----+--------------+---+----+--------------+---+---+- - - | |head|mbuf1 data |sh |head|mbuf2 data |sh | | | |room| |inf|room| |inf| | +--+----+--------------+---+----+--------------+---+---+- - - ^ | Metadata for the whole chunk, having another refcnt managed by PMD. fcb_opaque will have this pointer so that the callback func knows it. > To summarize, I like the idea of your patchset, this is close to > what I had in mind... which does not necessarly mean it is the good > way to do ;) > > I'm a bit afraid about ABI breakage, we need to check that a > 18.02-compiled application still works well with this change. I had the same concern so I made rte_pktmbuf_attach_extbuf() __rte_experimental. Although this new ol_flag is introduced, it can only be set by the new API and the rest of changes won't be effective unless this flag is set. RTE_MBUF_HAS_EXTBUF() will always be false if -DALLOW_EXPERIMENTAL_API isn't specified or rte_pktmbuf_attach_extbuf() isn't called. And there's no change needed in a C file. For this reason, I don't think there's ABI breakage. Sounds correct? > About testing, I don't know if you checked the mbuf autotests, > but it could also help to check that basic stuff still work. I'll make sure all the tests pass before I submit a new version. Thanks, Yongseok