Thread (23 messages) flat view 23 messages, 4 authors, 2021-02-17

Re: [Patch bpf-next v3 4/5] skmsg: use skb ext instead of TCP_SKB_CB

From: Cong Wang <hidden>
Date: 2021-02-16 00:29:14
Also in: bpf

On Mon, Feb 15, 2021 at 3:57 PM John Fastabend [off-list ref] wrote:
For TCP case we can continue to use CB and not pay the price. For UDP
and AF_UNIX we can do the extra alloc.
I see your point, but specializing TCP case does not give much benefit
here, the skmsg code would have to check skb->protocol etc. to decide
whether to use TCP_SKB_CB() or skb_ext:

if (skb->protocol == ...)
  TCP_SKB_CB(skb) = ...;
else
  ext = skb_ext_find(skb);

which looks ugly to me. And I doubt skb->protocol alone is sufficient to
distinguish TCP, so we may end up having more checks above.

So do you really want to trade code readability with an extra alloc?
The use in tcf_classify_ingress is a miss case so not the common path. If
it is/was in the common path I would suggest we rip it out.
Excellent point, what about nf_bridge_unshare()? It is a common path
for bridge netfilter, which is also probably why skb ext was introduced
(IIRC). secpath_set() seems on a common path for XFRM too.

Are you suggesting to remove them all? ;)

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help