Messages in this thread | | | Subject | Re: [PATCH net-next] net: tipc: fix FB_MTU eat two pages | From | Jon Maloy <> | Date | Wed, 9 Jun 2021 03:34:33 -0400 |
| |
On 6/8/21 10:54 PM, Menglong Dong wrote: > On Tue, Jun 08, 2021 at 06:37:38PM -0400, Jon Maloy wrote: >> > [...] >> I spent a little more time looking into this. I think the best we can do is >> to keep FB_MTU internal to msg.c, and then add an outline function to msg.c >> that can be used by bcast.c. The way it is used is never time critical. >> >> I also see that we could need a little cleanup around this. There is a >> redundant align() function that should be removed and replaced with the >> global ALIGN() macro. >> Even tipc_buf_acquire() should use this macro instead of the explicit method >> that is used now. >> In general, I stongly dislike conditional code, and it is not necessary in >> this function. If we redefine the non-crypto BUF_TAILROOM to 0 instead of 16 >> (it is not used anywhere else) we could get rid of this too. >> >> But I leave that to you. If you only fix the FB_MTU macro I am content. >> > Yeah, I think I can handle it, just leave it to me. > > (finger heart :/) > Menglong DongI 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?
///jon
>
| |