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: 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