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
