Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH net-next] net: tipc: fix FB_MTU eat two pages
To:     Menglong Dong <menglong8.dong@gmail.com>
Cc:     ying.xue@windriver.com, David Miller <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        tipc-discussion@lists.sourceforge.net,
        Menglong Dong <dong.menglong@zte.com.cn>,
        Zeal Robot <zealci@zte.com.cn>
References: <20210604074419.53956-1-dong.menglong@zte.com.cn>
 <e997a058-9f6e-86a0-8591-56b0b89441aa@redhat.com>
 <CADxym3ZostCAY0GwUpTxEHcOPyOj5Lmv4F7xP-Q4=AEAVaEAxw@mail.gmail.com>
 <998cce2c-b18d-59c1-df64-fc62856c63a1@redhat.com> <20210607125120.GA4262@www>
 <46d2a694-6a85-0f8e-4156-9bb1c4dbdb69@redhat.com>
 <20210609025412.GA58348@www>
From:   Jon Maloy <jmaloy@redhat.com>
Message-ID: <927af5e7-6194-d94e-1497-6b3dce26c583@redhat.com>
Date:   Wed, 9 Jun 2021 03:34:33 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <20210609025412.GA58348@www>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk


On 6/8/21 10:54 PM, Menglong Dong wrote:
> On Tue, Jun 08, 2021 at 06:37:38PM -0400, Jon Maloy wrote:
>>
> [...]
>> I spent a little more time looking into this. I think the best we can do is
>> to keep FB_MTU internal to msg.c, and then add an outline function to msg.c
>> that can be used by bcast.c. The way it is used is never time critical.
>>
>> I also see that we could need a little cleanup around this. There is a
>> redundant align() function that should be removed and replaced with the
>> global ALIGN() macro.
>> Even tipc_buf_acquire() should use this macro instead of the explicit method
>> that is used now.
>> In general, I stongly dislike conditional code, and it is not necessary in
>> this function. If we redefine the non-crypto BUF_TAILROOM to 0 instead of 16
>> (it is not used anywhere else) we could get rid of this too.
>>
>> But I leave that to you. If you only fix the FB_MTU macro I am content.
>>
> Yeah, I think I can handle it, just leave it to me.
>
> (finger heart :/)
> Menglong DongI
It seems like I have been misleading you. It turns out that these 
messages *will* be sent out over the nework in some cases, i.e. at 
multicast/broadcast over an UDP bearer.
So, what we need is two macros, one with the conditional crypto 
head/tailroom defined as you first suggested, and one that only use the 
non-crypto head/tailroom as we have been discussing now.
The first one can be defined inside bcast.c, the latter  inside msg.c.
It might also be a good idea to give the macros more descriptive names, 
such as ONEPAGE_MTU in the broadcast version, and ONEPAGE_SKB in the 
node local
version.

Does that make sense?

///jon


>