All of lore.kernel.org
 help / color / mirror / Atom feed
From: Larysa Zaremba <larysa.zaremba@intel.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: <bpf@vger.kernel.org>, Stanislav Fomichev <sdf@google.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	"KP Singh" <kpsingh@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Anatoly Burakov <anatoly.burakov@intel.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Alexander Lobakin <alexandr.lobakin@intel.com>,
	"Magnus Karlsson" <magnus.karlsson@gmail.com>,
	Maryam Tahhan <mtahhan@redhat.com>, <xdp-hints@xdp-project.net>,
	<netdev@vger.kernel.org>, <intel-wired-lan@lists.osuosl.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND bpf-next 03/15] ice: make RX checksum checking code more reusable
Date: Mon, 22 May 2023 18:05:04 +0200	[thread overview]
Message-ID: <ZGuSsBVFlEePio60@lincoln> (raw)
In-Reply-To: <6693bcdb-b5dc-2f5b-41fa-9a9bba909dc7@intel.com>

On Mon, May 22, 2023 at 05:51:37PM +0200, Alexander Lobakin wrote:
> From: Larysa Zaremba <larysa.zaremba@intel.com>
> Date: Fri, 12 May 2023 17:25:55 +0200
> 
> > Previously, we only needed RX checksum flags in skb path,
> > hence all related code was written with skb in mind.
> > But with the addition of XDP hints via kfuncs to the ice driver,
> > the same logic will be needed in .xmo_() callbacks.
> > 
> > Put generic process of determining checksum status into
> > a separate function.
> > 
> > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> > ---
> >  drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 71 ++++++++++++-------
> >  1 file changed, 46 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > index 1aab79dc8915..6a4fd3f3fc0a 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > @@ -104,17 +104,17 @@ ice_rx_hash_to_skb(struct ice_rx_ring *rx_ring,
> >  }
> >  
> >  /**
> > - * ice_rx_csum - Indicate in skb if checksum is good
> > - * @ring: the ring we care about
> > - * @skb: skb currently being received and modified
> > + * ice_rx_csum_checked - Indicates, whether hardware has checked the checksum
> 
> %CHECKSUM_UNNECESSARY means that the csum is correct / frame is not
> damaged. So "checked" is not enough I'd say, it's "verified" at least.
> OTOH that's too long already, I'd go with classic "csum_ok" :D

'csum_ok' sounds good :) 'csum_valid' if want to be fancy

> 
> >   * @rx_desc: the receive descriptor
> >   * @ptype: the packet type decoded by hardware
> > + * @csum_lvl_dst: address to put checksum level into
> > + * @ring: ring for error stats, can be NULL
> >   *
> > - * skb->protocol must be set before this function is called
> > + * Returns true, if hardware has checked the checksum.
> >   */
> > -static void
> > -ice_rx_csum(struct ice_rx_ring *ring, struct sk_buff *skb,
> > -	    union ice_32b_rx_flex_desc *rx_desc, u16 ptype)
> > +static bool
> > +ice_rx_csum_checked(union ice_32b_rx_flex_desc *rx_desc, u16 ptype,
> 
> (also const, but I guess you'll do that either way after the previous
>  mails)

OK

> 
> > +		    u8 *csum_lvl_dst, struct ice_rx_ring *ring)
> >  {
> >  	struct ice_rx_ptype_decoded decoded;
> >  	u16 rx_status0, rx_status1;
> 
> [...]
> 
> > +/**
> > + * ice_rx_csum_into_skb - Indicate in skb if checksum is good
> > + * @ring: the ring we care about
> > + * @skb: skb currently being received and modified
> > + * @rx_desc: the receive descriptor
> > + * @ptype: the packet type decoded by hardware
> > + */
> > +static void
> > +ice_rx_csum_into_skb(struct ice_rx_ring *ring, struct sk_buff *skb,
> > +		     union ice_32b_rx_flex_desc *rx_desc, u16 ptype)
> > +{
> > +	u8 csum_level = 0;
> 
> I'm not a fan of variables shorter than u32 on the stack. And since it
> gets passed by a reference, I'm not sure the compiler will inline it =\
> 
> > +
> > +	/* Start with CHECKSUM_NONE and by default csum_level = 0 */
> > +	skb->ip_summed = CHECKSUM_NONE;
> > +	skb_checksum_none_assert(skb);
> 
> Can we also remove this? Neither of these makes sense. ::ip_summed is
> always zeroed after the memset() in __build_skb_around() (somewhere
> there), while the assertion checks for `skb->ip_summed ==
> CHECKSUM_NONE`, i.e. it's *always* true here (set and check :D). It's
> some ancient pathetic rituals copied over and over again from e100
> centuries or so...

Will fix.

> 
> ...and BTW the comment is misleading, because the code doesn't zero
> ::csum_level as they claim :D
> 
> > +
> > +	/* check if Rx checksum is enabled */
> > +	if (!(ring->netdev->features & NETIF_F_RXCSUM))
> > +		return;
> > +
> > +	if (!ice_rx_csum_checked(rx_desc, ptype, &csum_level, ring))
> > +		return;
> > +
> > +	skb->ip_summed = CHECKSUM_UNNECESSARY;
> > +	skb->csum_level = csum_level;
> 
> Since csum_level is useless when ip_summed is set to NONE, what do you
> think about making the function return -1, 0, or 1 without writing
> anything by reference?
> 
> 	int csum_level;
> 
> 	csum_level = ice_rx_csum_ok(rx_desc, ptype, ring);
> 	if (csum_level < 0)
> 		return;
> 
> 	skb->ip_summed = CHECKSUM_UNNECESSARY;
> 	skb->csum_level = csum_level;
> 
> I'm not saying it's better (might be a bit at codegen), just proposing.

I think it's worth a try.

> 
> >  }
> >  
> >  /**
> > @@ -232,7 +253,7 @@ ice_process_skb_fields(struct ice_rx_ring *rx_ring,
> >  	/* modifies the skb - consumes the enet header */
> >  	skb->protocol = eth_type_trans(skb, rx_ring->netdev);
> >  
> > -	ice_rx_csum(rx_ring, skb, rx_desc, ptype);
> > +	ice_rx_csum_into_skb(rx_ring, skb, rx_desc, ptype);
> >  
> >  	if (rx_ring->ptp_rx)
> >  		ice_ptp_rx_hwts_to_skb(rx_ring, rx_desc, skb);
> 
> Thanks,
> Olek

WARNING: multiple messages have this Message-ID (diff)
From: Larysa Zaremba <larysa.zaremba@intel.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Anatoly Burakov <anatoly.burakov@intel.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>, Song Liu <song@kernel.org>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Stanislav Fomichev <sdf@google.com>,
	Maryam Tahhan <mtahhan@redhat.com>,
	xdp-hints@xdp-project.net, Daniel Borkmann <daniel@iogearbox.net>,
	John Fastabend <john.fastabend@gmail.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	intel-wired-lan@lists.osuosl.org,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Yonghong Song <yhs@fb.com>, KP Singh <kpsingh@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jiri Olsa <jolsa@kernel.org>,
	bpf@vger.kernel.org, Martin KaFai Lau <martin.lau@linux.dev>
Subject: Re: [Intel-wired-lan] [PATCH RESEND bpf-next 03/15] ice: make RX checksum checking code more reusable
Date: Mon, 22 May 2023 18:05:04 +0200	[thread overview]
Message-ID: <ZGuSsBVFlEePio60@lincoln> (raw)
In-Reply-To: <6693bcdb-b5dc-2f5b-41fa-9a9bba909dc7@intel.com>

On Mon, May 22, 2023 at 05:51:37PM +0200, Alexander Lobakin wrote:
> From: Larysa Zaremba <larysa.zaremba@intel.com>
> Date: Fri, 12 May 2023 17:25:55 +0200
> 
> > Previously, we only needed RX checksum flags in skb path,
> > hence all related code was written with skb in mind.
> > But with the addition of XDP hints via kfuncs to the ice driver,
> > the same logic will be needed in .xmo_() callbacks.
> > 
> > Put generic process of determining checksum status into
> > a separate function.
> > 
> > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> > ---
> >  drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 71 ++++++++++++-------
> >  1 file changed, 46 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > index 1aab79dc8915..6a4fd3f3fc0a 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > @@ -104,17 +104,17 @@ ice_rx_hash_to_skb(struct ice_rx_ring *rx_ring,
> >  }
> >  
> >  /**
> > - * ice_rx_csum - Indicate in skb if checksum is good
> > - * @ring: the ring we care about
> > - * @skb: skb currently being received and modified
> > + * ice_rx_csum_checked - Indicates, whether hardware has checked the checksum
> 
> %CHECKSUM_UNNECESSARY means that the csum is correct / frame is not
> damaged. So "checked" is not enough I'd say, it's "verified" at least.
> OTOH that's too long already, I'd go with classic "csum_ok" :D

'csum_ok' sounds good :) 'csum_valid' if want to be fancy

> 
> >   * @rx_desc: the receive descriptor
> >   * @ptype: the packet type decoded by hardware
> > + * @csum_lvl_dst: address to put checksum level into
> > + * @ring: ring for error stats, can be NULL
> >   *
> > - * skb->protocol must be set before this function is called
> > + * Returns true, if hardware has checked the checksum.
> >   */
> > -static void
> > -ice_rx_csum(struct ice_rx_ring *ring, struct sk_buff *skb,
> > -	    union ice_32b_rx_flex_desc *rx_desc, u16 ptype)
> > +static bool
> > +ice_rx_csum_checked(union ice_32b_rx_flex_desc *rx_desc, u16 ptype,
> 
> (also const, but I guess you'll do that either way after the previous
>  mails)

OK

> 
> > +		    u8 *csum_lvl_dst, struct ice_rx_ring *ring)
> >  {
> >  	struct ice_rx_ptype_decoded decoded;
> >  	u16 rx_status0, rx_status1;
> 
> [...]
> 
> > +/**
> > + * ice_rx_csum_into_skb - Indicate in skb if checksum is good
> > + * @ring: the ring we care about
> > + * @skb: skb currently being received and modified
> > + * @rx_desc: the receive descriptor
> > + * @ptype: the packet type decoded by hardware
> > + */
> > +static void
> > +ice_rx_csum_into_skb(struct ice_rx_ring *ring, struct sk_buff *skb,
> > +		     union ice_32b_rx_flex_desc *rx_desc, u16 ptype)
> > +{
> > +	u8 csum_level = 0;
> 
> I'm not a fan of variables shorter than u32 on the stack. And since it
> gets passed by a reference, I'm not sure the compiler will inline it =\
> 
> > +
> > +	/* Start with CHECKSUM_NONE and by default csum_level = 0 */
> > +	skb->ip_summed = CHECKSUM_NONE;
> > +	skb_checksum_none_assert(skb);
> 
> Can we also remove this? Neither of these makes sense. ::ip_summed is
> always zeroed after the memset() in __build_skb_around() (somewhere
> there), while the assertion checks for `skb->ip_summed ==
> CHECKSUM_NONE`, i.e. it's *always* true here (set and check :D). It's
> some ancient pathetic rituals copied over and over again from e100
> centuries or so...

Will fix.

> 
> ...and BTW the comment is misleading, because the code doesn't zero
> ::csum_level as they claim :D
> 
> > +
> > +	/* check if Rx checksum is enabled */
> > +	if (!(ring->netdev->features & NETIF_F_RXCSUM))
> > +		return;
> > +
> > +	if (!ice_rx_csum_checked(rx_desc, ptype, &csum_level, ring))
> > +		return;
> > +
> > +	skb->ip_summed = CHECKSUM_UNNECESSARY;
> > +	skb->csum_level = csum_level;
> 
> Since csum_level is useless when ip_summed is set to NONE, what do you
> think about making the function return -1, 0, or 1 without writing
> anything by reference?
> 
> 	int csum_level;
> 
> 	csum_level = ice_rx_csum_ok(rx_desc, ptype, ring);
> 	if (csum_level < 0)
> 		return;
> 
> 	skb->ip_summed = CHECKSUM_UNNECESSARY;
> 	skb->csum_level = csum_level;
> 
> I'm not saying it's better (might be a bit at codegen), just proposing.

I think it's worth a try.

> 
> >  }
> >  
> >  /**
> > @@ -232,7 +253,7 @@ ice_process_skb_fields(struct ice_rx_ring *rx_ring,
> >  	/* modifies the skb - consumes the enet header */
> >  	skb->protocol = eth_type_trans(skb, rx_ring->netdev);
> >  
> > -	ice_rx_csum(rx_ring, skb, rx_desc, ptype);
> > +	ice_rx_csum_into_skb(rx_ring, skb, rx_desc, ptype);
> >  
> >  	if (rx_ring->ptp_rx)
> >  		ice_ptp_rx_hwts_to_skb(rx_ring, rx_desc, skb);
> 
> Thanks,
> Olek
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2023-05-22 16:08 UTC|newest]

Thread overview: 108+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-12 15:25 [PATCH RESEND bpf-next 00/15] new kfunc XDP hints and ice implementation Larysa Zaremba
2023-05-12 15:25 ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 15:25 ` [PATCH RESEND bpf-next 01/15] ice: make RX hash reading code more reusable Larysa Zaremba
2023-05-12 15:25   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-19 16:46   ` Alexander Lobakin
2023-05-19 16:46     ` [Intel-wired-lan] " Alexander Lobakin
2023-05-22 15:03     ` Larysa Zaremba
2023-05-22 15:03       ` [Intel-wired-lan] " Larysa Zaremba
2023-05-22 15:36       ` Alexander Lobakin
2023-05-22 15:36         ` [Intel-wired-lan] " Alexander Lobakin
2023-05-12 15:25 ` [PATCH RESEND bpf-next 02/15] ice: make RX HW timestamp " Larysa Zaremba
2023-05-12 15:25   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-19 16:52   ` Alexander Lobakin
2023-05-19 16:52     ` [Intel-wired-lan] " Alexander Lobakin
2023-05-22 15:07     ` Larysa Zaremba
2023-05-22 15:07       ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 15:25 ` [PATCH RESEND bpf-next 03/15] ice: make RX checksum checking " Larysa Zaremba
2023-05-12 15:25   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-22 15:51   ` Alexander Lobakin
2023-05-22 15:51     ` [Intel-wired-lan] " Alexander Lobakin
2023-05-22 16:05     ` Larysa Zaremba [this message]
2023-05-22 16:05       ` Larysa Zaremba
2023-05-12 15:25 ` [PATCH RESEND bpf-next 04/15] ice: Make ptype internal to descriptor info processing Larysa Zaremba
2023-05-12 15:25   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 15:25 ` [PATCH RESEND bpf-next 05/15] ice: Introduce ice_xdp_buff Larysa Zaremba
2023-05-12 15:25   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-22 16:46   ` Alexander Lobakin
2023-05-22 16:46     ` [Intel-wired-lan] " Alexander Lobakin
2023-05-23  8:02     ` Larysa Zaremba
2023-05-23  8:02       ` [Intel-wired-lan] " Larysa Zaremba
2023-05-25 11:02       ` Alexander Lobakin
2023-05-25 11:02         ` [Intel-wired-lan] " Alexander Lobakin
2023-05-12 15:25 ` [PATCH RESEND bpf-next 06/15] ice: Support HW timestamp hint Larysa Zaremba
2023-05-12 15:25   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 18:19   ` Stanislav Fomichev
2023-05-12 18:19     ` [Intel-wired-lan] " Stanislav Fomichev
2023-05-16 16:17     ` Jesper Dangaard Brouer
2023-05-16 16:17       ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-05-12 15:25 ` [PATCH RESEND bpf-next 07/15] ice: Support RX hash XDP hint Larysa Zaremba
2023-05-12 15:25   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 18:22   ` Stanislav Fomichev
2023-05-12 18:22     ` [Intel-wired-lan] " Stanislav Fomichev
2023-05-15 13:46     ` Larysa Zaremba
2023-05-15 13:46       ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 15:26 ` [PATCH RESEND bpf-next 08/15] ice: Support XDP hints in AF_XDP ZC mode Larysa Zaremba
2023-05-12 15:26   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 15:26 ` [PATCH RESEND bpf-next 09/15] xdp: Add VLAN tag hint Larysa Zaremba
2023-05-12 15:26   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 18:28   ` Stanislav Fomichev
2023-05-12 18:28     ` [Intel-wired-lan] " Stanislav Fomichev
2023-05-15 15:36   ` Jesper Dangaard Brouer
2023-05-15 15:36     ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-05-15 16:09     ` Larysa Zaremba
2023-05-15 16:09       ` [Intel-wired-lan] " Larysa Zaremba
2023-05-22  8:37       ` Jesper Dangaard Brouer
2023-05-22  8:37         ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-05-22 15:48         ` Larysa Zaremba
2023-05-22 15:48           ` [Intel-wired-lan] " Larysa Zaremba
2023-05-23 10:16           ` Jesper Dangaard Brouer
2023-05-23 10:16             ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-05-23 17:35             ` Larysa Zaremba
2023-05-23 17:35               ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 15:26 ` [PATCH RESEND bpf-next 10/15] ice: Implement " Larysa Zaremba
2023-05-12 15:26   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 18:31   ` Stanislav Fomichev
2023-05-12 18:31     ` [Intel-wired-lan] " Stanislav Fomichev
2023-05-15 13:41     ` Larysa Zaremba
2023-05-15 13:41       ` [Intel-wired-lan] " Larysa Zaremba
2023-05-15 15:07       ` Jesper Dangaard Brouer
2023-05-15 15:07         ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-05-15 15:45         ` Larysa Zaremba
2023-05-15 15:45           ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 15:26 ` [PATCH RESEND bpf-next 11/15] xdp: Add checksum level hint Larysa Zaremba
2023-05-12 15:26   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 18:34   ` Stanislav Fomichev
2023-05-12 18:34     ` [Intel-wired-lan] " Stanislav Fomichev
2023-05-15 13:49     ` Larysa Zaremba
2023-05-15 13:49       ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 15:26 ` [PATCH RESEND bpf-next 12/15] ice: Implement " Larysa Zaremba
2023-05-12 15:26   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 15:26 ` [PATCH RESEND bpf-next 13/15] selftests/bpf: Allow VLAN packets in xdp_hw_metadata Larysa Zaremba
2023-05-12 15:26   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 18:33   ` Stanislav Fomichev
2023-05-12 18:33     ` [Intel-wired-lan] " Stanislav Fomichev
2023-05-15 14:05     ` Larysa Zaremba
2023-05-15 14:05       ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 15:26 ` [PATCH RESEND bpf-next 14/15] net, xdp: allow metadata > 32 Larysa Zaremba
2023-05-12 15:26   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-15 16:17   ` Jesper Dangaard Brouer
2023-05-15 16:17     ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-05-15 17:08     ` Larysa Zaremba
2023-05-15 17:08       ` [Intel-wired-lan] " Larysa Zaremba
2023-05-16 12:37       ` Alexander Lobakin
2023-05-16 12:37         ` [Intel-wired-lan] " Alexander Lobakin
2023-05-16 15:35         ` Jesper Dangaard Brouer
2023-05-16 15:35           ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-05-19 16:35           ` Alexander Lobakin
2023-05-19 16:35             ` [Intel-wired-lan] " Alexander Lobakin
2023-05-22 11:41             ` Jesper Dangaard Brouer
2023-05-22 11:41               ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-05-22 15:28               ` Alexander Lobakin
2023-05-22 15:28                 ` [Intel-wired-lan] " Alexander Lobakin
2023-05-22 15:55                 ` Daniel Borkmann
2023-05-22 15:55                   ` [Intel-wired-lan] " Daniel Borkmann
2023-05-12 15:26 ` [PATCH RESEND bpf-next 15/15] selftests/bpf: Add flags and new hints to xdp_hw_metadata Larysa Zaremba
2023-05-12 15:26   ` [Intel-wired-lan] " Larysa Zaremba
2023-05-12 18:37   ` Stanislav Fomichev
2023-05-12 18:37     ` [Intel-wired-lan] " Stanislav Fomichev

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=ZGuSsBVFlEePio60@lincoln \
    --to=larysa.zaremba@intel.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=alexandr.lobakin@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=andrii@kernel.org \
    --cc=anthony.l.nguyen@intel.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=magnus.karlsson@gmail.com \
    --cc=martin.lau@linux.dev \
    --cc=mtahhan@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=xdp-hints@xdp-project.net \
    --cc=yhs@fb.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.