lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <89831a73-89c5-c5b6-d345-72908d8db304@nvidia.com> Date: Mon, 22 May 2023 15:47:15 +0300 From: Shay Drory <shayd@...dia.com> To: Jakub Kicinski <kuba@...nel.org>, Saeed Mahameed <saeed@...nel.org> CC: "David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>, Saeed Mahameed <saeedm@...dia.com>, <netdev@...r.kernel.org>, Tariq Toukan <tariqt@...dia.com>, Moshe Shemesh <moshe@...dia.com> Subject: Re: [PATCH net-next] net/mlx5: Introduce SF direction On 20/05/2023 7:41, Jakub Kicinski wrote: > External email: Use caution opening links or attachments > > > On Fri, 19 May 2023 11:30:44 -0700 Saeed Mahameed wrote: >> Whenever multiple Virtual Network functions (VNFs) are used by Service >> Function Chaining (SFC), each packet is passing through all the VNFs, >> and each VNF is performing hairpin in order to pass the packet to the >> next function in the chain. >> >> In case one mlx5 NIC is servicing multiple VNFs of the SFC, mlx5 need >> user input in order to optimize this hairpin to a simple forward rule. >> >> The optimization is performed by binding two PCI SFs to each VNF, as >> can be seen bellow: >> >> ----------- ----------- >> | VNF1 | | VNF2 | >> ----------- ----------- >> | | | | >> (Net) SF1| |SF2 (Net) SF3| |SF4 >> | | | | >> ------------------------------- >> | / \________________/ \ | >> uplink---|/ \|----host >> | NIC(SFC) | >> | | >> ------------------------------- >> >> Define SF1 and SF3 as SFs with network direction tell the driver to >> configure the E-switch in a way that the packet arriving from SF1 will >> do forward to SF2 instead of hairpin. >> >> This marking is done via sfnum command line argument, where bit 16 >> marks the SF as facing the Network, and bit 17 marks the SF as >> facing the Host. > What does it mean that an SF is "facing" the network? Facing the physical wire, like an UPLINK vport. > Why can't the device automatically "optimize" the hairpin? Our FW/HW can do steering optimization if we know the direction in advance. > Or SF1 / SF2 will be uni-directional after this patch? No. every SF will continue to be bi-directional. the change will only affect steering optimization. > -- > pw-bot: cr
Powered by blists - more mailing lists