> On Thu, Jan 13, 2022 at 2:22 AM Lorenzo Bianconi <lorenzo@xxxxxxxxxx> wrote: > > > > > > > > > > I would prefer to keep the "_mb" postfix, but naming is hard and I am > > > > > polarized :) > > > > > > > > I would lean towards keeping _mb as well, but if it does have to be > > > > changed why not _mbuf? At least that's not quite as verbose :) > > > > > > I dislike the "mb" abbreviation as I forget it stands for multi-buffer. > > > I like the "mbuf" suggestion, even-though it conflicts with (Free)BSD mbufs > > > (which is their SKB). > > > > If we all agree, I can go over the series and substitute mb postfix with mbuf. > > Any objections? > > mbuf has too much bsd taste. > > How about ".frags" instead? I am fine with this (for me it is better than mb or mbuf). Do we all agree or do we prefer the "mb" suffix? > Then xdp_buff_is_mb() will be xdp_buff_has_frags(). > > I agree that it's not obvious what "mb" suffix stands for, > but I don't buy at all that it can be confused with "megabyte". > It's the context that matters. > In "100mb" it's obvious that "mb" is likely "megabyte", > but in "xdp.mb" it's certainly not "xdp megabyte". > Such a sentence has no meaning. > Imagine we used that suffix for "tc"... > it would be "tc.mb"... "Traffic Control Megabyte" ?? > > Anyway "xdp.frags" ? agree > > Btw "xdp_cpumap" should be cleaned up. > xdp_cpumap is an attach type. It's not prog type. > Probably it should be "xdp/cpumap" to align with "cgroup/bind[46]" ? so for xdp "mb" or xdp "frags" it will be xdp/cpumap.mb (xdp/devmap.mb) or xdp/cpumap.frags (xdp/devmap.frags), right? > > In patch 22 there is a comment: > /* try to attach BPF_XDP_DEVMAP multi-buff program" > > It creates further confusion. There is no XDP_DEVMAP program type. > It should probably read > "Attach BPF_XDP program with frags to devmap" ack, I will fix it. > > Patch 21 still has "CHECK". Pls replace it with ASSERT. ack, I will fix it. Regards, Lorenzo
Attachment:
signature.asc
Description: PGP signature
