> -----Original Message----- > From: Akhil Goyal <gak...@marvell.com> > Sent: Monday, June 24, 2024 4:28 PM > To: Suanming Mou <suanmi...@nvidia.com>; Matan Azrad > <ma...@nvidia.com> > Cc: dev@dpdk.org > Subject: RE: [EXTERNAL] [PATCH v2 1/2] crypto/mlx5: optimize AES-GCM > IPsec operation > > > Just to be more accurate, in fact our current PMD has supported IPsec > > already via UMR's way. This series is an optimization, not newly > > supporting IPsec, but to optimize the IPsec input case. > > And like I replied above, it is not the patches invites the layout and > > require user to have such buffers, but the truth is we want to better > > serve the IPsec input come with that layout case in the real world as API > does not reject that IPsec input. > > Ok got it. > > But if we set the devarg for a mlx5 device, it will be a hint to the PMD for > all > the flows that it will process. Right?
Yes, right. If the devarg is set, means user knows he only has that IPsec inputs for all the flows. If not, user will not set that devarg. > > And there may be an application use case where it has 2 separate flows > simultaneously - IPsec and non-IPsec. > > Then how would PMD handle that? > Will it assume contiguous memory for non-IPsec case as well? > How will PMD identify between IPsec and non-IPsec case? In that case, user will not set the devarg, PMD will always use UMR WQE to build contiguous memory address space for HW. No matter it is IPsec or non-IPsec. Background: UMR WQE is a powerful WQE can generate new contiguous new address space with several inputs. e.g.: If we have 3 non-contiguous inputs addr_a, addr_b, addr_c, UMR WQE can generate a new addr_d with these 3 memory address space combined. The only disadvantage is that UMR WQE is a bit heavy for using in the simple IPsec case. So we add that small optimization if user only use IPsec as inputs. > > Thanks, Suanming
