Hello, Ilya Lesokhin <il...@mellanox.com> writes:
> Hannes Frederic Sowa <han...@stressinduktion.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. IMHO the decision if a TCP flow should be bounded to hw and thus never push traffic to another interface should a decision the administrator and the application should opt in. You might have your management application which is accessible over multiple interfaces and your production application which might want to use hw offloaded tls. Thus I don't think only a single ethtool knob will do it. I agree that SO_BINDTODEVICE is bad for this use case. First, the CAP_NET_RAW limitation seems annoying and we don't want to enforce TLS apps to have this capability. Second, the user space application doesn't care which interface it should talk to (maybe?) but leave the routing decision to the kernel and just opt in to TLS. SO_BINDTODEVICE doesn't allow this. sk_bound_dev_if can be rebound later with CAP_NET_RAW privileges, will this be a problem? Have you thought how the user space will configure the various offloading features (sw, hw, none)? Will it in e.g. OpenSSL be part of the Cipher Spec or will there be new functions around SSL_CTX to do so? Maybe an enhancement of the TLS_TX setsockopt with a boolean for hw offload is a solution? Another question: How is the dependency management done between socket layer and driver layer? It seems a bit cyclic but judging from this code you don't hold references to the device (dev_hold) (which is good, you don't want to have users creating refs to devices). OTOH you somehow need to match sockets from the device layer up to the socket. Will those be reference counted or does that work without? Thanks, Hannes
