Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Message-ID: <4f2ce89f-a018-4a43-97b6-e9d43020e158@daynix.com>
Date:   Mon, 9 Oct 2023 04:52:56 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 1/7] net: skbuff: Add tun_vnet_hash flag
Content-Language: en-US
To:     Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc:     Jason Wang <jasowang@redhat.com>,
        "Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        virtualization@lists.linux-foundation.org,
        linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
        davem@davemloft.net, kuba@kernel.org, ast@kernel.org,
        daniel@iogearbox.net, andrii@kernel.org, kafai@fb.com,
        songliubraving@fb.com, yhs@fb.com, john.fastabend@gmail.com,
        kpsingh@kernel.org, rdunlap@infradead.org, willemb@google.com,
        gustavoars@kernel.org, herbert@gondor.apana.org.au,
        steffen.klassert@secunet.com, nogikh@google.com,
        pablo@netfilter.org, decui@microsoft.com, cai@lca.pw,
        jakub@cloudflare.com, elver@google.com, pabeni@redhat.com,
        Yuri Benditovich <yuri.benditovich@daynix.com>
References: <20231008052101.144422-1-akihiko.odaki@daynix.com>
 <20231008052101.144422-2-akihiko.odaki@daynix.com>
 <CAF=yD-K0RR5XCuPdHS8gPwppM-HAmodSOVBpS=v+j8X7=Su2Rg@mail.gmail.com>
From:   Akihiko Odaki <akihiko.odaki@daynix.com>
In-Reply-To: <CAF=yD-K0RR5XCuPdHS8gPwppM-HAmodSOVBpS=v+j8X7=Su2Rg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 2023/10/09 3:39, Willem de Bruijn wrote:
> On Sun, Oct 8, 2023 at 7:22 AM Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
>>
>> tun_vnet_hash can use this flag to indicate it stored virtio-net hash
>> cache to cb.
>>
>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>> ---
>>   include/linux/skbuff.h | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 4174c4b82d13..e638f157c13c 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -837,6 +837,7 @@ typedef unsigned char *sk_buff_data_t;
>>    *     @truesize: Buffer size
>>    *     @users: User count - see {datagram,tcp}.c
>>    *     @extensions: allocated extensions, valid if active_extensions is nonzero
>> + *     @tun_vnet_hash: tun stored virtio-net hash cache to cb
>>    */
>>
>>   struct sk_buff {
>> @@ -989,6 +990,7 @@ struct sk_buff {
>>   #if IS_ENABLED(CONFIG_IP_SCTP)
>>          __u8                    csum_not_inet:1;
>>   #endif
>> +       __u8                    tun_vnet_hash:1;
> 
> sk_buff space is very limited.
> 
> No need to extend it, especially for code that stays within a single
> subsystem (tun).
> 
> To a lesser extent the same point applies to the qdisc_skb_cb.

I had to extend sk_buff because it does not stay in tun but moves back 
and forth between qdisc and tun.

The new members of sk_buff and qdisc_skb_cb are stored by tun's 
ndo_select_queue(). The control will go back to qdisc after 
ndo_select_queue() function finishes. Eventually tun's ndo_start_xmit() 
will be called by qdisc and consumes the stored members. qdisc is 
required to keep the stored members intact.

tun_vnet_hash is a bit special. It is put into sk_buff because 
ndo_select_queue() is not always called and it may be left 
uninitialized. ndo_start_xmit() may read some garbage from cb's old user 
if it is put into cb.