[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM4PR0501MB2723F6F5A22955102CDC2886D4600@AM4PR0501MB2723.eurprd05.prod.outlook.com>
Date: Tue, 19 Sep 2017 07:36:28 +0000
From: Ilya Lesokhin <ilyal@...lanox.com>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"davejwatson@...com" <davejwatson@...com>,
"tom@...bertland.com" <tom@...bertland.com>,
Boris Pismenny <borisp@...lanox.com>,
Aviad Yehezkel <aviadye@...lanox.com>,
Liran Liss <liranl@...lanox.com>
Subject: RE: [PATCH net-next 5/5] tls: Add generic NIC offload infrastructure.
Hannes Frederic Sowa <hannes@...essinduktion.org> writes:
> The user should be aware of that they can't migrate the socket to another
> interface if they got hw offloaded. This is not the case for software offload.
> Thus I think the user has to opt in and it shouldn't be a heuristic until we can
> switch back to sw offload path.
>
> Maybe change flowi_oif to sk_bound_dev_if and somwhow lock it against
> further changes if hw tls is in use?
>
I'm not sure I follow.
We do set sk->sk_bound_dev_if to prevent further changes.
Do you recommend we enable TLS offload only if SO_BINDTODEVICE
was previously used on that socket?
and prevent even users with CAP_NET_RAW from unbinding it?
I would rather avoid requiring CAP_NET_RAW to use TLS offload.
But admittedly I'm not sure setting sk->sk_bound_dev_if
without CAP_NET_RAW like we do is legit either.
Finally, the reason we made HW offload the default is that the user
can use sudo ethtool -K enp0s4 tls-hw-tx-offload off to opt out of HW offload
and we currently don't have anything equivalent for opting out of SW KTLS.
Thanks,
Ilya
Powered by blists - more mailing lists