Subject: Re: [PATCH net-next v11 08/23] ovpn: implement basic TX path (UDP)

From: Sabrina Dubroca <[email-masked]>
Date: Tue, 12 Nov 2024 18:28:08 +0100

2024-11-11, 00:32:51 +0200, Sergey Ryazanov wrote:
> On 29.10.2024 12:47, Antonio Quartulli wrote:
> > +static void ovpn_encrypt_post(struct sk_buff *skb, int ret)
> > +{
> > +	struct ovpn_peer *peer = ovpn_skb_cb(skb)->peer;
> > +
> > +	if (unlikely(ret < 0))
> > +		goto err;
> > +
> > +	skb_mark_not_on_list(skb);
> > +
> > +	switch (peer->sock->sock->sk->sk_protocol) {
> > +	case IPPROTO_UDP:
> > +		ovpn_udp_send_skb(peer->ovpn, peer, skb);
> > +		break;
> > +	default:
> > +		/* no transport configured yet */
> > +		goto err;
> > +	}
> 
> Did you consider calling protocol specific sending function indirectly?
> E.g.:
> 
>         peer->sock->send(peer, skb);

In a case where
 - only 2 implementations exist
 - no other implementation is likely to be added in the future
 - both implementations are part of the same module

I don't think indirect calls are beneficial (especially after the
meltdown/etc mitigations, see for example 4f24ed77dec9 ("udp: use
indirect call wrappers for GRO socket lookup"), 0e219ae48c3b ("net:
use indirect calls helpers for L3 handler hooks"), and many others
similar patches).

[...]
> > +	ovpn_send(ovpn, skb_list.next, NULL);
> > +
> > +	return NETDEV_TX_OK;
> > +
> > +drop:
> >   	skb_tx_error(skb);
> > -	kfree_skb(skb);
> > +	kfree_skb_list(skb);
> >   	return NET_XMIT_DROP;
> >   }
> > diff --git a/drivers/net/ovpn/peer.c b/drivers/net/ovpn/peer.c
> > index d9788a0cc99b5839c466c35d1b2266cc6b95fb72..aff3e9e99b7d2dd2fa68484d9a396d43f75a6d0b 100644
> > --- a/drivers/net/ovpn/peer.c
> > +++ b/drivers/net/ovpn/peer.c

[very long chunk of Antonio's patch quoted without comments]

Please trim your replies to only the necessary context.

-- 
Sabrina