netdev - Re: [PATCH net-next] net/mlx5: Introduce SF direction

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 19 May 2023 21:41:01 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: 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>, Shay Drory <shayd@...dia.com>, Moshe Shemesh
 <moshe@...dia.com>
Subject: Re: [PATCH net-next] net/mlx5: Introduce SF direction

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?
Why can't the device automatically "optimize" the hairpin?
Or SF1 / SF2 will be uni-directional after this patch?
-- 
pw-bot: cr