-----Original Message-----
From: Jon Maloy <jma...@redhat.com>
Sent: Thursday, June 10, 2021 4:12 PM
To: Menglong Dong <menglong8.d...@gmail.com>
Cc: ying....@windriver.com; tipc-discussion@lists.sourceforge.net; Xin Long
<l...@redhat.com>; tipc-dek <tipc-...@dektech.com.au>
Subject: Re: [PATCH v2 net-next 0/2] net: tipc: fix FB_MTU eat two pages and do
some code cleanup
On 6/9/21 8:56 AM, Menglong Dong wrote:
On Wed, Jun 9, 2021 at 6:47 PM Jon Maloy <jma...@redhat.com> wrote:
On 6/9/21 6:32 AM, menglong8.d...@gmail.com wrote:
From: Menglong Dong <dong.mengl...@zte.com.cn
[...]
No, no, I didn't miss your mail. I think it can make us clear about what and how
to do by sending the V2 patches.
So we can define two versions 'FB_MTU' for bcast.c and msg.c, such as CRYPTO_MTU
and NON_CRYPTO_MTU. And within tipc_buf_acquire(), we decide which version
BUF_HEADROOM to use by the data size? Such as:
int buf_size;
if (IS_ENABLED(CONFIG_TIPC_CRYPTO) && size == NON_CRYPTO_MTU) {
buf_size = size + BUF_HEADROOM_non-crypto + BUF_TAILROOM_non-crypto;
} else {
buf_size = size + BUF_HEADROOM_crypto + BUF_TAILROOM_crypto;
}
Is this feeling?
(It's a little weird to check whether the data should be crypto by data size).
Thanks!
Menglong Dong
(Removed netdev, David Miller etc from thread)
I think our main mistake is that we are trying to "compensate" for a
behavior in tipc_buf_acquire() that doens't fit our purposes.
What if we do the following:
1) We define BUF_HEADROOM and BUF_TAILROOM as we do now, plus a FB_MTU
as you suggest, all inside msg.c.
2) We create a new inline function tipc_alloc_skb(int headroom, int
tailroom, int size) in msg.c
This function does the job that tipc_buf_acqire() does now.
3) We let tipc_buf_acquire() call this function as
tipc_alloc_skb(BUF_HEADROOM, BUF_TAILROOM, size);
Alternatively, we skip the BUF_HEADROOM/BUF_TAILROOM macros
altogether andmake the code in tipc_buf_acquire() conditional as you
did, but without testing for size. Actually, I think I like this better.
Maybe even better: we keep BUF_HEADROOM, but only define it as
LL_MAX_HEADER + 48, i.e. the non-crypto value.
We still keep the conditional call in tipc_buf_acquire(), and add the
crypto-header extras explictly when needed.
That way, we only need to change in one place if we decide to expand the
headroom.
///jon
4) We let the fallback function in msg.c call it as
tipc_alloc_skb(LL_MAX_HEADER + 48, 0, ONEPAGE_SKB);
5) We let the user in bcast.c get acces to the calculated value of
FB_MTU as a function or global value, like you did in v2.
I suggest you send v3 to tipc-discussion (if you are a member) and the
recipients of this mail first, so we don't spam the netdev list with
intermediate versions of this series.
///jon
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
