| Message ID | 20240710111654.4085575-1-yumike@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Support IPsec crypto offload for IPv6 ESP and IPv4 UDP-encapsulated ESP data paths | expand |
On Wed, Jul 10, 2024 at 07:16:50PM +0800, Mike Yu wrote: > Currently, IPsec crypto offload is enabled for GRO code path. However, there > are other code paths where the XFRM stack is involved; for example, IPv6 ESP > packets handled by xfrm6_esp_rcv() in ESP layer, and IPv4 UDP-encapsulated > ESP packets handled by udp_rcv() in UDP layer. > > This patchset extends the crypto offload support to cover these two cases. > This is useful for devices with traffic accounting (e.g., Android), where GRO > can lead to inaccurate accounting on the underlying network. For example, VPN > traffic might not be counted on the wifi network interface wlan0 if the packets > are handled in GRO code path before entering the network stack for accounting. > > Below is the RX data path scenario the crypto offload can be applied to. > > +-----------+ +-------+ > | HW Driver |-->| wlan0 |--------+ > +-----------+ +-------+ | > v > +---------------+ +------+ > +------>| Network Stack |-->| Apps | > | +---------------+ +------+ > | | > | v > +--------+ +------------+ > | ipsec1 |<--| XFRM Stack | > +--------+ +------------+ > > v2 -> v3: > - Correct ESP seq in esp_xmit(). > v1 -> v2: > - Fix comment style. > > Mike Yu (4): > xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO > path > xfrm: Allow UDP encapsulation in crypto offload control path > xfrm: Support crypto offload for inbound IPv4 UDP-encapsulated ESP > packet > xfrm: Support crypto offload for outbound IPv4 UDP-encapsulated ESP > packet > > net/ipv4/esp4.c | 8 +++++++- > net/ipv4/esp4_offload.c | 17 ++++++++++++++++- > net/xfrm/xfrm_device.c | 6 +++--- > net/xfrm/xfrm_input.c | 3 ++- > net/xfrm/xfrm_policy.c | 5 ++++- > 5 files changed, 32 insertions(+), 7 deletions(-) Steffen, If it helps, we tested v2 version and it didn't break anything for us :). But we didn't test this specific functionality. Thanks > > -- > 2.45.2.803.g4e1b14247a-goog > >
On Thu, Jul 11, 2024 at 12:52:08PM +0300, Leon Romanovsky wrote: > On Wed, Jul 10, 2024 at 07:16:50PM +0800, Mike Yu wrote: > > > > Mike Yu (4): > > xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO > > path > > xfrm: Allow UDP encapsulation in crypto offload control path > > xfrm: Support crypto offload for inbound IPv4 UDP-encapsulated ESP > > packet > > xfrm: Support crypto offload for outbound IPv4 UDP-encapsulated ESP > > packet > > > > net/ipv4/esp4.c | 8 +++++++- > > net/ipv4/esp4_offload.c | 17 ++++++++++++++++- > > net/xfrm/xfrm_device.c | 6 +++--- > > net/xfrm/xfrm_input.c | 3 ++- > > net/xfrm/xfrm_policy.c | 5 ++++- > > 5 files changed, 32 insertions(+), 7 deletions(-) > > Steffen, > > If it helps, we tested v2 version and it didn't break anything for us :). > But we didn't test this specific functionality. > > Thanks Thanks for testing it Leon! This is a new feature, so I don't want to apply it to the ipsec tree. Mike, can you rebase on top of ipsec-next instead? Thanks!
Sure. The patch series were already based on ipsec-next. Sent v4 that targets ipsec-next tree. Mike Mike On Thu, Jul 11, 2024 at 6:11 PM Steffen Klassert <steffen.klassert@secunet.com> wrote: > > On Thu, Jul 11, 2024 at 12:52:08PM +0300, Leon Romanovsky wrote: > > On Wed, Jul 10, 2024 at 07:16:50PM +0800, Mike Yu wrote: > > > > > > Mike Yu (4): > > > xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO > > > path > > > xfrm: Allow UDP encapsulation in crypto offload control path > > > xfrm: Support crypto offload for inbound IPv4 UDP-encapsulated ESP > > > packet > > > xfrm: Support crypto offload for outbound IPv4 UDP-encapsulated ESP > > > packet > > > > > > net/ipv4/esp4.c | 8 +++++++- > > > net/ipv4/esp4_offload.c | 17 ++++++++++++++++- > > > net/xfrm/xfrm_device.c | 6 +++--- > > > net/xfrm/xfrm_input.c | 3 ++- > > > net/xfrm/xfrm_policy.c | 5 ++++- > > > 5 files changed, 32 insertions(+), 7 deletions(-) > > > > Steffen, > > > > If it helps, we tested v2 version and it didn't break anything for us :). > > But we didn't test this specific functionality. > > > > Thanks > > Thanks for testing it Leon! > > This is a new feature, so I don't want to apply it to the ipsec > tree. Mike, can you rebase on top of ipsec-next instead? > > Thanks!
Currently, IPsec crypto offload is enabled for GRO code path. However, there are other code paths where the XFRM stack is involved; for example, IPv6 ESP packets handled by xfrm6_esp_rcv() in ESP layer, and IPv4 UDP-encapsulated ESP packets handled by udp_rcv() in UDP layer. This patchset extends the crypto offload support to cover these two cases. This is useful for devices with traffic accounting (e.g., Android), where GRO can lead to inaccurate accounting on the underlying network. For example, VPN traffic might not be counted on the wifi network interface wlan0 if the packets are handled in GRO code path before entering the network stack for accounting. Below is the RX data path scenario the crypto offload can be applied to. +-----------+ +-------+ | HW Driver |-->| wlan0 |--------+ +-----------+ +-------+ | v +---------------+ +------+ +------>| Network Stack |-->| Apps | | +---------------+ +------+ | | | v +--------+ +------------+ | ipsec1 |<--| XFRM Stack | +--------+ +------------+ v2 -> v3: - Correct ESP seq in esp_xmit(). v1 -> v2: - Fix comment style. Mike Yu (4): xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO path xfrm: Allow UDP encapsulation in crypto offload control path xfrm: Support crypto offload for inbound IPv4 UDP-encapsulated ESP packet xfrm: Support crypto offload for outbound IPv4 UDP-encapsulated ESP packet net/ipv4/esp4.c | 8 +++++++- net/ipv4/esp4_offload.c | 17 ++++++++++++++++- net/xfrm/xfrm_device.c | 6 +++--- net/xfrm/xfrm_input.c | 3 ++- net/xfrm/xfrm_policy.c | 5 ++++- 5 files changed, 32 insertions(+), 7 deletions(-)