From: Jon M. <jm...@re...> - 2021-06-10 12:44:41
|
> -----Original Message----- > From: Jon Maloy <jm...@re...> > Sent: Thursday, June 10, 2021 4:12 PM > To: Menglong Dong <men...@gm...> > Cc: yin...@wi...; tip...@li...; Xin Long <lx...@re...>; tipc-dek <tip...@de...> > 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 <jm...@re...> wrote: >>> >>> On 6/9/21 6:32 AM, men...@gm... wrote: >>>> From: Menglong Dong <don...@zt... [...] >> 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 > > |