netdev - Re: [PATCH] net/smc: Add autocork support

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] [day] [month] [year] [list]

Date:   Sat, 26 Feb 2022 07:42:11 +0800
From:   "dust.li" <dust.li@...ux.alibaba.com>
To:     Karsten Graul <kgraul@...ux.ibm.com>,
        Hendrik Brueckner <brueckner@...ux.ibm.com>
Cc:     Stefan Raspl <raspl@...ux.ibm.com>,
        Tony Lu <tonylu@...ux.alibaba.com>, kuba@...nel.org,
        davem@...emloft.net, netdev@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-rdma@...r.kernel.org
Subject: Re: [PATCH] net/smc: Add autocork support

On Fri, Feb 25, 2022 at 07:10:40PM +0100, Karsten Graul wrote:
>On 24/02/2022 03:02, dust.li wrote:
>> On Wed, Feb 23, 2022 at 07:57:31PM +0100, Karsten Graul wrote:
>>> On 19/02/2022 00:42, dust.li wrote:
>>>> On Fri, Feb 18, 2022 at 05:03:56PM +0100, Karsten Graul wrote:
>>>>> Right now for me it looks like there is no way to use netlink for container runtime
>>>>> configuration, which is a pity.
>>>>> We continue our discussions about this in the team, and also here on the list.
>>>>
>>>> Many thanks for your time on this topic !
>>>
>>> We checked more specs (like Container Network Interface (CNI) Specification) 
>>> but all we found uses sysctl at the end. There is lot of infrastructure 
>>> to use sysctls in a container environment.
>>>
>>> Establishing netlink-like controls for containers is by far out of our scope, and
>>> would take a long time until it would be available in the popular projects.
>>>
>>> So at the moment I see no alternative to an additional sysctl interface in the 
>>> SMC module that provides controls which are useful in container environments.
>> 
>> Got it, I will add sysctl interface and a switch with this function.
>> 
>> Thank again !
>
>Can you explain again why this auto_cork needs a switch to disable it?
>My understanding is that this auto_cork makes always sense and is triggered
>when there are not enough resources.

My initial intention to provide a switch is to be like TCP to let user
to disable it. For user cases like debug and workaround bugs if it is
associated with auto cork, or compare performance like I did (But this
should not be a real world case in production environment).

But after Stefan suggested that we make the auto corked size turnable,
I realized that we can only need one sysctl switch: which tunes the auto
corked bytes size. Disable auto cork can be archived by setting this to 0.

Something like this bellow:
static bool smc_should_autocork(struct smc_sock *smc)
{
        struct smc_connection *conn = &smc->conn;
        int corking_size;

        corking_size = min(sock_net(&smc->sk)->smc.sysctl_autocorking_size,
                           conn->sndbuf_desc->len >> 1);

        if (atomic_read(&conn->cdc_pend_tx_wr) == 0 ||
            smc_tx_prepared_sends(conn) > corking_size)
                return false;
        return true;
}

Thanks.