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
Date: Wed, 9 Jun 2021 03:53:50 -0700 [thread overview]
Message-ID: <20210609105350.GA64468@www> (raw)
In-Reply-To: <927af5e7-6194-d94e-1497-6b3dce26c583@redhat.com>
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
>
> >
prev parent reply other threads:[~2021-06-09 10:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-04 7:44 [PATCH net-next] net: tipc: fix FB_MTU eat two pages menglong8.dong
2021-06-04 19:20 ` Jon Maloy
2021-06-05 1:28 ` Menglong Dong
2021-06-05 14:25 ` Jon Maloy
2021-06-06 14:40 ` Menglong Dong
2021-06-07 12:51 ` Menglong Dong
2021-06-08 22:37 ` Jon Maloy
2021-06-09 2:54 ` Menglong Dong
2021-06-09 7:34 ` Jon Maloy
2021-06-09 10:53 ` Menglong Dong [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210609105350.GA64468@www \
--to=menglong8.dong@gmail.com \
--cc=davem@davemloft.net \
--cc=dong.menglong@zte.com.cn \
--cc=jmaloy@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tipc-discussion@lists.sourceforge.net \
--cc=ying.xue@windriver.com \
--cc=zealci@zte.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.