netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander H Duyck <alexander.duyck@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Cc: netdev <netdev@vger.kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	Coco Li <lixiaoyan@google.com>
Subject: Re: [PATCH net-next 05/15] ipv6/gso: remove temporary HBH/jumbo header
Date: Thu, 03 Feb 2022 10:53:07 -0800	[thread overview]
Message-ID: <0d3cbdeee93fe7b72f3cdfc07fd364244d3f4f47.camel@gmail.com> (raw)
In-Reply-To: <20220203015140.3022854-6-eric.dumazet@gmail.com>

On Wed, 2022-02-02 at 17:51 -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
> 
> ipv6 tcp and gro stacks will soon be able to build big TCP packets,
> with an added temporary Hop By Hop header.
> 
> If GSO is involved for these large packets, we need to remove
> the temporary HBH header before segmentation happens.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
>  include/net/ipv6.h | 31 +++++++++++++++++++++++++++++++
>  net/core/skbuff.c  | 21 ++++++++++++++++++++-
>  2 files changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> index ea2a4351b654f8bc96503aae2b9adcd478e1f8b2..96e916fb933c3e7d4288e86790fcb2bb1353a261 100644
> --- a/include/net/ipv6.h
> +++ b/include/net/ipv6.h
> @@ -464,6 +464,37 @@ bool ipv6_opt_accepted(const struct sock *sk, const struct sk_buff *skb,
>  struct ipv6_txoptions *ipv6_update_options(struct sock *sk,
>  					   struct ipv6_txoptions *opt);
>  
> +/* This helper is specialized for BIG TCP needs.
> + * It assumes the hop_jumbo_hdr will immediately follow the IPV6 header.
> + * It assumes headers are already in skb->head, thus the sk argument is only read.
> + */
> +static inline bool ipv6_has_hopopt_jumbo(const struct sk_buff *skb)
> +{
> +	struct hop_jumbo_hdr *jhdr;
> +	struct ipv6hdr *nhdr;
> +
> +	if (likely(skb->len <= GRO_MAX_SIZE))
> +		return false;
> +
> +	if (skb->protocol != htons(ETH_P_IPV6))
> +		return false;
> +
> +	if (skb_network_offset(skb) +
> +	    sizeof(struct ipv6hdr) +
> +	    sizeof(struct hop_jumbo_hdr) > skb_headlen(skb))
> +		return false;
> +
> +	nhdr = ipv6_hdr(skb);
> +
> +	if (nhdr->nexthdr != NEXTHDR_HOP)
> +		return false;
> +
> +	jhdr = (struct hop_jumbo_hdr *) (nhdr + 1);
> +	if (jhdr->tlv_type != IPV6_TLV_JUMBO || jhdr->hdrlen != 0)
> +		return false;
> +	return true;

Rather than having to perform all of these checkes would it maybe make
sense to add SKB_GSO_JUMBOGRAM as a gso_type flag? Then it would make
it easier for drivers to indicate if they support the new offload or
not.

An added bonus is that it would probably make it easier to do something
like a GSO_PARTIAL for this since then it would just be a matter of
flagging it, stripping the extra hop-by-hop header, and chopping it
into gso_max_size chunks.

> +}
> +
>  static inline bool ipv6_accept_ra(struct inet6_dev *idev)
>  {
>  	/* If forwarding is enabled, RA are not accepted unless the special
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 0118f0afaa4fce8da167ddf39de4c9f3880ca05b..53f17c7392311e7123628fcab4617efc169905a1 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3959,8 +3959,9 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
>  	skb_frag_t *frag = skb_shinfo(head_skb)->frags;
>  	unsigned int mss = skb_shinfo(head_skb)->gso_size;
>  	unsigned int doffset = head_skb->data - skb_mac_header(head_skb);
> +	int hophdr_len = sizeof(struct hop_jumbo_hdr);
>  	struct sk_buff *frag_skb = head_skb;
> -	unsigned int offset = doffset;
> +	unsigned int offset;
>  	unsigned int tnl_hlen = skb_tnl_header_len(head_skb);
>  	unsigned int partial_segs = 0;
>  	unsigned int headroom;
> @@ -3968,6 +3969,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
>  	__be16 proto;
>  	bool csum, sg;
>  	int nfrags = skb_shinfo(head_skb)->nr_frags;
> +	struct ipv6hdr *h6;
>  	int err = -ENOMEM;
>  	int i = 0;
>  	int pos;
> @@ -3992,6 +3994,23 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
>  	}
>  
>  	__skb_push(head_skb, doffset);
> +
> +	if (ipv6_has_hopopt_jumbo(head_skb)) {
> +		/* remove the HBH header.
> +		 * Layout: [Ethernet header][IPv6 header][HBH][TCP header]
> +		 */
> +		memmove(head_skb->data + hophdr_len,
> +			head_skb->data,
> +			ETH_HLEN + sizeof(struct ipv6hdr));
> +		head_skb->data += hophdr_len;
> +		head_skb->len -= hophdr_len;
> +		head_skb->network_header += hophdr_len;
> +		head_skb->mac_header += hophdr_len;
> +		doffset -= hophdr_len;
> +		h6 = (struct ipv6hdr *)(head_skb->data + ETH_HLEN);
> +		h6->nexthdr = IPPROTO_TCP;
> +	}

Does it really make the most sense to be doing this here, or should
this be a part of the IPv6 processing? It seems like of asymmetric when
compared with the change in the next patch to add the header in GRO.

> +	offset = doffset;
>  	proto = skb_network_protocol(head_skb, NULL);
>  	if (unlikely(!proto))
>  		return ERR_PTR(-EINVAL);



  reply	other threads:[~2022-02-03 18:53 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-03  1:51 [PATCH net-next 00/15] tcp: BIG TCP implementation Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 01/15] net: add netdev->tso_ipv6_max_size attribute Eric Dumazet
2022-02-03 16:34   ` Jakub Kicinski
2022-02-03 16:56     ` Eric Dumazet
2022-02-03 18:58       ` Jakub Kicinski
2022-02-03 19:12         ` Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 02/15] ipv6: add dev->gso_ipv6_max_size Eric Dumazet
2022-02-03  8:57   ` Paolo Abeni
2022-02-03 15:34     ` Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 03/15] tcp_cubic: make hystart_ack_delay() aware of BIG TCP Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 04/15] ipv6: add struct hop_jumbo_hdr definition Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 05/15] ipv6/gso: remove temporary HBH/jumbo header Eric Dumazet
2022-02-03 18:53   ` Alexander H Duyck [this message]
2022-02-03 19:17     ` Eric Dumazet
2022-02-03 19:45       ` Alexander Duyck
2022-02-03 19:59         ` Eric Dumazet
2022-02-03 21:08           ` Alexander H Duyck
2022-02-03 21:41             ` Eric Dumazet
2022-02-04  0:05               ` Alexander Duyck
2022-02-04  0:27                 ` Eric Dumazet
2022-02-04  1:14                   ` Eric Dumazet
2022-02-04  1:48                     ` Eric Dumazet
2022-02-04  2:15                       ` Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 06/15] ipv6/gro: insert " Eric Dumazet
2022-02-03  9:19   ` Paolo Abeni
2022-02-03 15:48     ` Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 07/15] ipv6: add GRO_IPV6_MAX_SIZE Eric Dumazet
2022-02-03  2:18   ` Eric Dumazet
2022-02-03 10:44   ` Paolo Abeni
2022-02-03  1:51 ` [PATCH net-next 08/15] ipv6: Add hop-by-hop header to jumbograms in ip6_output Eric Dumazet
2022-02-03  9:07   ` Paolo Abeni
2022-02-03 16:31     ` Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 09/15] net: increase MAX_SKB_FRAGS Eric Dumazet
2022-02-03  5:02   ` kernel test robot
2022-02-03  5:20     ` Eric Dumazet
2022-02-03  5:31       ` Jakub Kicinski
2022-02-03  6:35         ` Eric Dumazet
2022-02-03  5:23   ` kernel test robot
2022-02-03  5:43   ` kernel test robot
2022-02-03 16:01   ` Paolo Abeni
2022-02-03 17:26   ` Alexander H Duyck
2022-02-03 17:34     ` Eric Dumazet
2022-02-03 17:56       ` Alexander Duyck
2022-02-03 19:18         ` Jakub Kicinski
2022-02-03 19:20           ` Eric Dumazet
2022-02-03 19:54             ` Eric Dumazet
2022-02-04 10:18         ` David Laight
2022-02-04 15:46           ` Alexander Duyck
2022-02-03  1:51 ` [PATCH net-next 10/15] net: loopback: enable BIG TCP packets Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 11/15] bonding: update dev->tso_ipv6_max_size Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 12/15] macvlan: enable BIG TCP Packets Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 13/15] ipvlan: " Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 14/15] mlx4: support BIG TCP packets Eric Dumazet
2022-02-03 13:04   ` Tariq Toukan
2022-02-03 15:54     ` Eric Dumazet
2022-02-03  1:51 ` [PATCH net-next 15/15] mlx5: " Eric Dumazet
2022-02-03  7:27   ` Tariq Toukan
2022-02-04  4:03   ` kernel test robot

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=0d3cbdeee93fe7b72f3cdfc07fd364244d3f4f47.camel@gmail.com \
    --to=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=kuba@kernel.org \
    --cc=lixiaoyan@google.com \
    --cc=netdev@vger.kernel.org \
    /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 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).