All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Hopps <chopps@chopps.org>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Christian Hopps <chopps@chopps.org>,
	devel@linux-ipsec.org, netdev@vger.kernel.org,
	Florian Westphal <fw@strlen.de>,
	Sabrina Dubroca <sd@queasysnail.net>,
	Simon Horman <horms@kernel.org>,
	Antony Antony <antony@phenome.org>,
	Christian Hopps <chopps@labn.net>
Subject: Re: [PATCH ipsec-next v12 10/16] xfrm: iptfs: add fragmenting of larger than MTU user packets
Date: Sat, 02 Nov 2024 15:50:42 +0000	[thread overview]
Message-ID: <m2v7x5iq56.fsf@chopps.org> (raw)
In-Reply-To: <ZxYhHQ1xDW69EiDM@gauss3.secunet.de>

[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]


Steffen Klassert <steffen.klassert@secunet.com> writes:

> On Mon, Oct 07, 2024 at 09:59:22AM -0400, Christian Hopps wrote:
>> From: Christian Hopps <chopps@labn.net>
>>
>> Add support for tunneling user (inner) packets that are larger than the
>> tunnel's path MTU (outer) using IP-TFS fragmentation.
>>
>> Signed-off-by: Christian Hopps <chopps@labn.net>
>> ---
>>  net/xfrm/xfrm_iptfs.c | 350 ++++++++++++++++++++++++++++++++++++++----
>>  1 file changed, 321 insertions(+), 29 deletions(-)
>>
>> diff --git a/net/xfrm/xfrm_iptfs.c b/net/xfrm/xfrm_iptfs.c
>> index 627b10ed4db0..7343ed77160c 100644
>> --- a/net/xfrm/xfrm_iptfs.c
>> +++ b/net/xfrm/xfrm_iptfs.c
>> @@ -46,12 +46,29 @@
>>   */
>>  #define IPTFS_DEFAULT_MAX_QUEUE_SIZE	(1024 * 10240)
>>
>> +/* Assumed: skb->head is cache aligned.
>> + *
>> + * L2 Header resv: Arrange for cacheline to start at skb->data - 16 to keep the
>> + * to-be-pushed L2 header in the same cacheline as resulting `skb->data` (i.e.,
>> + * the L3 header). If cacheline size is > 64 then skb->data + pushed L2 will all
>> + * be in a single cacheline if we simply reserve 64 bytes.
>> + *
>> + * L3 Header resv: For L3+L2 headers (i.e., skb->data points at the IPTFS payload)
>> + * we want `skb->data` to be cacheline aligned and all pushed L2L3 headers will
>> + * be in their own cacheline[s]. 128 works for cachelins up to 128 bytes, for
>> + * any larger cacheline sizes the pushed headers will simply share the cacheline
>> + * with the start of the IPTFS payload (skb->data).
>> + */
>> +#define XFRM_IPTFS_MIN_L3HEADROOM 128
>> +#define XFRM_IPTFS_MIN_L2HEADROOM (L1_CACHE_BYTES > 64 ? 64 : 64 + 16)
>> +
>>  #define NSECS_IN_USEC 1000
>>
>>  #define IPTFS_HRTIMER_MODE HRTIMER_MODE_REL_SOFT
>>
>>  /**
>>   * struct xfrm_iptfs_config - configuration for the IPTFS tunnel.
>> + * @dont_frag: true to inhibit fragmenting across IPTFS outer packets.
>>   * @pkt_size: size of the outer IP packet. 0 to use interface and MTU discovery,
>>   *	otherwise the user specified value.
>>   * @max_queue_size: The maximum number of octets allowed to be queued to be sent
>> @@ -59,6 +76,7 @@
>>   *	packets enqueued.
>>   */
>>  struct xfrm_iptfs_config {
>> +	bool dont_frag : 1;
>
> This bool creates a two byte hole at the beginning of the structure.
> Not a big issue here, but usually it is good to check the structure
> layout with pahole to avoid this.

Moved to bottom changed to `u8 dont_frag : 1`

>
>>  	u32 pkt_size;	    /* outer_packet_size or 0 */
>>  	u32 max_queue_size; /* octets */
>>  };


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

  reply	other threads:[~2024-11-02 15:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-07 13:59 [PATCH ipsec-next v12 00/16] Add IP-TFS mode to xfrm Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 01/16] xfrm: config: add CONFIG_XFRM_IPTFS Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 02/16] include: uapi: add ip_tfs_*_hdr packet formats Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 03/16] include: uapi: add IPPROTO_AGGFRAG for AGGFRAG in ESP Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 04/16] xfrm: netlink: add config (netlink) options Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 05/16] xfrm: add mode_cbs module functionality Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 06/16] xfrm: add generic iptfs defines and functionality Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 07/16] xfrm: iptfs: add new iptfs xfrm mode impl Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 08/16] xfrm: iptfs: add user packet (tunnel ingress) handling Christian Hopps
2024-10-21  9:30   ` Steffen Klassert
2024-11-02 15:44     ` Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 09/16] xfrm: iptfs: share page fragments of inner packets Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 10/16] xfrm: iptfs: add fragmenting of larger than MTU user packets Christian Hopps
2024-10-21  9:38   ` Steffen Klassert
2024-11-02 15:50     ` Christian Hopps [this message]
2024-10-07 13:59 ` [PATCH ipsec-next v12 11/16] xfrm: iptfs: add basic receive packet (tunnel egress) handling Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 12/16] xfrm: iptfs: handle received fragmented inner packets Christian Hopps
2024-10-21 10:26   ` Steffen Klassert
2024-11-02 16:01     ` Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 13/16] xfrm: iptfs: add reusing received skb for the tunnel egress packet Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 14/16] xfrm: iptfs: add skb-fragment sharing code Christian Hopps
2024-10-21 10:39   ` Steffen Klassert
2024-11-02 16:26     ` Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 15/16] xfrm: iptfs: handle reordering of received packets Christian Hopps
2024-10-21  8:21   ` Steffen Klassert
2024-11-02 16:30     ` Christian Hopps
2024-10-07 13:59 ` [PATCH ipsec-next v12 16/16] xfrm: iptfs: add tracepoint functionality Christian Hopps

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2v7x5iq56.fsf@chopps.org \
    --to=chopps@chopps.org \
    --cc=antony@phenome.org \
    --cc=chopps@labn.net \
    --cc=devel@linux-ipsec.org \
    --cc=fw@strlen.de \
    --cc=horms@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sd@queasysnail.net \
    --cc=steffen.klassert@secunet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.