netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RFC ipsec-next 0/5] IPsec GRO layer decapsulation
@ 2017-02-07  9:14 Steffen Klassert
  2017-02-07  9:14 ` [PATCH RFC ipsec-next 1/5] xfrm: Add a secpath_set helper Steffen Klassert
                   ` (4 more replies)
  0 siblings, 5 replies; 12+ messages in thread
From: Steffen Klassert @ 2017-02-07  9:14 UTC (permalink / raw)
  To: netdev
  Cc: Steffen Klassert, David Miller, Eric Dumazet, Sowmini Varadhan,
	Ilan Tayari

This patchset adds a software GRO codepath for IPsec ESP.
The ESP gro_receive callback functions decapsulate the
ESP packets at the GRO layer and reinject them back with
gro_cells_receive(). This saves a complete round through
the stack for IPsec ESP packets.

We also need this for ESP HW offload, because HW decrypt but
does not decapsulate the packet. We need to decapsulate before
the inbound policy check, otherwise this check will fail.

Patches 2 an 3 prepare the generic code for packet consuming
gro callbacks.

^ permalink raw reply	[flat|nested] 12+ messages in thread
* [PATCH RFC ipsec-next] IPsec offload, part one
@ 2017-01-04  8:23 Steffen Klassert
  2017-01-04  8:23 ` [PATCH RFC ipsec-next 5/5] esp: Add a software GRO codepath Steffen Klassert
  0 siblings, 1 reply; 12+ messages in thread
From: Steffen Klassert @ 2017-01-04  8:23 UTC (permalink / raw)
  To: David Miller, netdev; +Cc: Steffen Klassert, Sowmini Varadhan, Ilan Tayari

This is the first part of the IPsec offload work we
talked at the IPsec workshop at the last netdev
conference. I plan to apply this to ipsec-next
after this round of review.

Patch 1 and 2 try to avoid skb linearization in
the ESP layer.

Patch 3 introduces a hepler to seup the esp trailer.

Patch 4 prepares the generic network code for
IPsec GRO. The main reason why we need this, is
that we need to reinject the decrypted inner
packet back to the GRO layer.

Patch 5 introduces GRO handlers for ESP, GRO
can enabled with a IPsec offload config option.
This config option will also be used for the
upcomming hardware offload.

David, patch 3 touches generic networking code.
Is it ok to integrate such a generic preparation
patch into an IPsec pull request, or do you
prefer to get it as a separate patch?

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2017-02-10  7:39 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-07  9:14 [PATCH RFC ipsec-next 0/5] IPsec GRO layer decapsulation Steffen Klassert
2017-02-07  9:14 ` [PATCH RFC ipsec-next 1/5] xfrm: Add a secpath_set helper Steffen Klassert
2017-02-08 18:18   ` David Miller
2017-02-07  9:14 ` [PATCH RFC ipsec-next 2/5] net: Add a skb_gro_flush_final helper Steffen Klassert
2017-02-07  9:14 ` [PATCH RFC ipsec-next 3/5] net: Prepare gro for packet consuming gro callbacks Steffen Klassert
2017-02-07  9:14 ` [PATCH RFC ipsec-next 4/5] xfrm: Export xfrm_parse_spi Steffen Klassert
2017-02-07  9:14 ` [PATCH RFC ipsec-next 5/5] esp: Add a software GRO codepath Steffen Klassert
2017-02-07 19:45   ` Eric Dumazet
2017-02-08 11:43     ` Steffen Klassert
2017-02-08 18:19   ` David Miller
2017-02-10  7:39     ` Steffen Klassert
  -- strict thread matches above, loose matches on Subject: below --
2017-01-04  8:23 [PATCH RFC ipsec-next] IPsec offload, part one Steffen Klassert
2017-01-04  8:23 ` [PATCH RFC ipsec-next 5/5] esp: Add a software GRO codepath Steffen Klassert

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).