lkml.org 
[lkml]   [2021]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net-next] net: tipc: fix FB_MTU eat two pages
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

>
> >

\
 
 \ /
  Last update: 2021-06-09 12:55    [W:0.190 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site