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;
Date:   Wed, 9 Jun 2021 03:53:50 -0700
From:   Menglong Dong <menglong8.dong@gmail.com>
To:     Jon Maloy <jmaloy@redhat.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>
Subject: Re: [PATCH net-next] net: tipc: fix FB_MTU eat two pages
Message-ID: <20210609105350.GA64468@www>
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>
 <927af5e7-6194-d94e-1497-6b3dce26c583@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <927af5e7-6194-d94e-1497-6b3dce26c583@redhat.com>
Precedence: bulk

On Wed, Jun 09, 2021 at 03:34:33AM -0400, Jon Maloy wrote:
> 
> 
[...]
> 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?

I think it's another point which can be optimized. However, with
CONFIG_TIPC_CRYPTO=y, the BUF_HEADROOM used in tipc_buf_acquire() is
always the crypto version, so it donen't work to define FB_MTU with
non-crypto BUF_HEADROOM.

So the point is to make a non-crypto version tipc_buf_acquire(), which
is used to alloc data for non-crypto message with non-crypto
BUF_HEADROOM. And that require us to distinguish the message that don't
crypto. Is there simple way to achieve this goal?

(Btw, I resended the patches for the 'two pages' problems.)

Thanks!
Menglong Dong

> 
> >