[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1887416432.225095145.1639141032334.JavaMail.zimbra@uliege.be>
Date: Fri, 10 Dec 2021 13:57:12 +0100 (CET)
From: Justin Iurman <justin.iurman@...ege.be>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, dsahern@...nel.org,
yoshfuji@...ux-ipv6.org, linux-mm@...ck.org, cl@...ux.com,
penberg@...nel.org, rientjes@...gle.com,
iamjoonsoo kim <iamjoonsoo.kim@....com>,
akpm@...ux-foundation.org, vbabka@...e.cz,
Roopa Prabhu <roopa@...dia.com>,
Nikolay Aleksandrov <nikolay@...dia.com>,
Andrew Lunn <andrew@...n.ch>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Vladimir Oltean <olteanv@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Florian Westphal <fw@...len.de>,
Paolo Abeni <pabeni@...hat.com>
Subject: Re: [RFC net-next 2/2] ipv6: ioam: Support for Buffer occupancy
data field
>> Indeed, would be a better fit. I didn't know about this one, thanks for
>> that. It's a shame it can't be used in this context, though. But, at the
>> end of the day, we're left with nothing regarding buffer occupancy. So
>> I'm wondering if "something" is not better than "nothing" in this case.
>> And, for that, we're back to my previous answer on why I agree and
>> disagree with what you said about its utility.
>
> I think we're on the same page, the main problem is I've not seen
> anyone use the skbuff_head_cache occupancy as a signal in practice.
Indeed.
> I'm adding a bunch of people to the CC list, hopefully someone has
> an opinion one way or the other.
+1, thanks Jakub.
> Lore link to the full thread, FWIW:
>
> https://lore.kernel.org/all/20211206211758.19057-1-justin.iurman@uliege.be/
Powered by blists - more mailing lists