> -----Original Message----- > From: David Marchand <david.march...@redhat.com> > Sent: Tuesday, June 20, 2023 2:10 PM > To: dev@dpdk.org > Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) <tho...@monjalon.net>; > i.maxim...@ovn.org; Ali Alnubani <alia...@nvidia.com>; Aman Singh > <aman.deep.si...@intel.com>; Yuying Zhang <yuying.zh...@intel.com>; > Matan Azrad <ma...@nvidia.com>; Slava Ovsiienko > <viachesl...@nvidia.com>; Ori Kam <or...@nvidia.com>; Suanming Mou > <suanmi...@nvidia.com>; David Christensen <d...@linux.vnet.ibm.com>; > Ruifeng Wang <ruifeng.w...@arm.com>; Bruce Richardson > <bruce.richard...@intel.com>; Konstantin Ananyev > <konstantin.v.anan...@yandex.ru>; Andrew Rybchenko > <andrew.rybche...@oktetlabs.ru>; Ferruh Yigit <ferruh.yi...@amd.com> > Subject: [RFC PATCH v3] ethdev: advertise flow restore in mbuf > > As reported by Ilya [1], unconditionally calling > rte_flow_get_restore_info() impacts an application performance for drivers > that do not provide this ops. > It could also impact processing of packets that require no call to > rte_flow_get_restore_info() at all. > > Register a dynamic mbuf flag when an application negotiates tunnel > metadata delivery (calling rte_eth_rx_metadata_negotiate() with > RTE_ETH_RX_METADATA_TUNNEL_ID). > > Drivers then advertise that metadata can be extracted by setting this > dynamic flag in each mbuf. > > The application then calls rte_flow_get_restore_info() only when required. > > Link: http://inbox.dpdk.org/dev/5248c2ca-f2a6-3fb0-38b8- > 7f659bfa4...@ovn.org/ > Signed-off-by: David Marchand <david.march...@redhat.com> > ---
Didn't see a degradation in packet forwarding performance on ConnectX-6 Dx and BlueField-2. Tested-by: Ali Alnubani <alia...@nvidia.com> Thanks
