From: Larysa Zaremba <larysa.zaremba@intel.com>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Cc: <bpf@vger.kernel.org>, <ast@kernel.org>, <daniel@iogearbox.net>,
<andrii@kernel.org>, <martin.lau@linux.dev>, <song@kernel.org>,
<yhs@fb.com>, <john.fastabend@gmail.com>, <kpsingh@kernel.org>,
<sdf@google.com>, <haoluo@google.com>, <jolsa@kernel.org>,
David Ahern <dsahern@gmail.com>, Jakub Kicinski <kuba@kernel.org>,
Willem de Bruijn <willemb@google.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Anatoly Burakov <anatoly.burakov@intel.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>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Simon Horman <simon.horman@corigine.com>,
Tariq Toukan <tariqt@mellanox.com>,
Saeed Mahameed <saeedm@mellanox.com>
Subject: Re: [xdp-hints] [RFC bpf-next 03/23] ice: make RX checksum checking code more reusable
Date: Wed, 6 Sep 2023 11:28:39 +0200 [thread overview]
Message-ID: <ZPhGRylHigicNNSv@lincoln> (raw)
In-Reply-To: <ZPdpALUo6CveX4Oc@boxer>
On Tue, Sep 05, 2023 at 07:44:32PM +0200, Maciej Fijalkowski wrote:
> On Tue, Sep 05, 2023 at 06:53:37PM +0200, Larysa Zaremba wrote:
> > On Tue, Sep 05, 2023 at 05:37:27PM +0200, Maciej Fijalkowski wrote:
> > > On Mon, Sep 04, 2023 at 08:01:06PM +0200, Larysa Zaremba wrote:
> > > > On Mon, Sep 04, 2023 at 05:02:40PM +0200, Maciej Fijalkowski wrote:
> > > > > On Thu, Aug 24, 2023 at 09:26:42PM +0200, Larysa Zaremba wrote:
> > > > > > 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.
> > > > > >
> > > > > > Now we cannot operate directly on skb, when deducing
> > > > > > checksum status, therefore introduce an intermediate enum for checksum
> > > > > > status. Fortunately, in ice, we have only 4 possibilities: checksum
> > > > > > validated at level 0, validated at level 1, no checksum, checksum error.
> > > > > > Use 3 bits for more convenient conversion.
> > > > > >
> > > > > > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> > > > > > ---
> > > > > > drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 105 ++++++++++++------
> > > > > > 1 file changed, 69 insertions(+), 36 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > > > > > index b2f241b73934..8b155a502b3b 100644
> > > > > > --- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > > > > > +++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> > > > > > @@ -102,18 +102,41 @@ ice_rx_hash_to_skb(const struct ice_rx_ring *rx_ring,
> > > > > > skb_set_hash(skb, hash, ice_ptype_to_htype(rx_ptype));
> > > > > > }
> > > > > >
> > > > > > +enum ice_rx_csum_status {
> > > > > > + ICE_RX_CSUM_LVL_0 = 0,
> > > > > > + ICE_RX_CSUM_LVL_1 = BIT(0),
> > > > > > + ICE_RX_CSUM_NONE = BIT(1),
> > > > > > + ICE_RX_CSUM_ERROR = BIT(2),
> > > > > > + ICE_RX_CSUM_FAIL = ICE_RX_CSUM_NONE | ICE_RX_CSUM_ERROR,
> > > > > > +};
> > > > > > +
> > > > > > /**
> > > > > > - * 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_lvl - Get checksum level from status
> > > > > > + * @status: driver-specific checksum status
> > >
> > > nit: describe retval?
> > >
> >
> > I think that kernel-doc is already too much for a one-liner.
> > Also, checksum level is fully explained in sk_buff documentation.
> >
> > > > > > + */
> > > > > > +static u8 ice_rx_csum_lvl(enum ice_rx_csum_status status)
> > > > > > +{
> > > > > > + return status & ICE_RX_CSUM_LVL_1;
> > > > > > +}
> > > > > > +
> > > > > > +/**
> > > > > > + * ice_rx_csum_ip_summed - Checksum status from driver-specific to generic
> > > > > > + * @status: driver-specific checksum status
> > >
> > > ditto
> >
> > Same as above. Moreover, there are only 2 possible return values that anyone can
> > easily look up. Describing them here would only balloon the file length.
>
> You really think 5 additional lines would balloon the file length? :D
>
> I am not sure what to say here. We have many pretty pointless kdoc retval
> descriptions like 'returns 0 on success, error otherwise' but to me this
> is following the guidelines from Documentation/doc-guide/kernel-doc.rst.
> If i generate kdoc I don't want to open up the source code to easily look
> up retvals.
>
> Just my 0.02$, not a thing that I'd like to keep on arguing on :)
>
I have consulted with the team and we came to a conclusion that maybe removing
kernel-doc for these functions would be the best solution. In ice, functions in
source files are always documented, but I do not think this rule is set in
stone.
Sorry, if I was being rude, I had been traumatized by documentaion requirements
at my previous job (automotive) :D
> >
> > >
> > > > > > + */
> > > > > > +static u8 ice_rx_csum_ip_summed(enum ice_rx_csum_status status)
> > > > > > +{
> > > > > > + return status & ICE_RX_CSUM_NONE ? CHECKSUM_NONE : CHECKSUM_UNNECESSARY;
> > > > >
> > > > > return !(status & ICE_RX_CSUM_NONE);
> > > > >
> > > > > ?
> > > >
> > > > status & ICE_RX_CSUM_NONE ? CHECKSUM_NONE : CHECKSUM_UNNECESSARY;
> > > >
> > > > is immediately understandable and results in 3 asm operations (I have checked):
> > > >
> > > > result = status >> 1;
> > > > result ^= 1;
> > > > result &= 1;
> > > >
> > > > I do not think "!(status & ICE_RX_CSUM_NONE);" could produce less.
> > >
> > > oh, nice. Just the fact that branch being added caught my eye.
> > >
> > > (...)
next prev parent reply other threads:[~2023-09-06 9:37 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 19:26 [RFC bpf-next 00/23] XDP metadata via kfuncs for ice + mlx5 Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 01/23] ice: make RX hash reading code more reusable Larysa Zaremba
2023-09-04 14:37 ` [xdp-hints] " Maciej Fijalkowski
2023-09-06 12:23 ` Alexander Lobakin
2023-09-14 16:12 ` Alexander Lobakin
2023-09-14 16:15 ` Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 02/23] ice: make RX HW timestamp " Larysa Zaremba
2023-09-04 14:56 ` Maciej Fijalkowski
2023-09-04 16:29 ` Larysa Zaremba
2023-09-05 15:22 ` Maciej Fijalkowski
2023-08-24 19:26 ` [RFC bpf-next 03/23] ice: make RX checksum checking " Larysa Zaremba
2023-09-04 15:02 ` [xdp-hints] " Maciej Fijalkowski
2023-09-04 18:01 ` Larysa Zaremba
2023-09-05 15:37 ` Maciej Fijalkowski
2023-09-05 16:53 ` Larysa Zaremba
2023-09-05 17:44 ` Maciej Fijalkowski
2023-09-06 9:28 ` Larysa Zaremba [this message]
2023-08-24 19:26 ` [RFC bpf-next 04/23] ice: Make ptype internal to descriptor info processing Larysa Zaremba
2023-09-04 15:04 ` Maciej Fijalkowski
2023-08-24 19:26 ` [RFC bpf-next 05/23] ice: Introduce ice_xdp_buff Larysa Zaremba
2023-09-04 15:32 ` [xdp-hints] " Maciej Fijalkowski
2023-09-04 18:11 ` Larysa Zaremba
2023-09-05 17:53 ` Maciej Fijalkowski
2023-09-07 14:21 ` Larysa Zaremba
2023-09-07 16:33 ` Stanislav Fomichev
2023-09-07 16:42 ` Maciej Fijalkowski
2023-09-07 16:43 ` Maciej Fijalkowski
2023-09-13 15:40 ` Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 06/23] ice: Support HW timestamp hint Larysa Zaremba
2023-09-04 15:38 ` Maciej Fijalkowski
2023-09-04 18:12 ` Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 07/23] ice: Support RX hash XDP hint Larysa Zaremba
2023-09-05 15:42 ` [xdp-hints] " Maciej Fijalkowski
2023-09-05 17:09 ` Larysa Zaremba
2023-09-06 12:03 ` Alexander Lobakin
2023-09-14 16:54 ` Alexander Lobakin
2023-09-14 16:59 ` Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 08/23] ice: Support XDP hints in AF_XDP ZC mode Larysa Zaremba
2023-09-04 15:42 ` [xdp-hints] " Maciej Fijalkowski
2023-09-04 18:14 ` Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 09/23] xdp: Add VLAN tag hint Larysa Zaremba
2023-08-24 22:02 ` kernel test robot
2023-09-14 16:18 ` Alexander Lobakin
2023-09-14 16:21 ` Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 10/23] ice: Implement " Larysa Zaremba
2023-09-04 16:00 ` Maciej Fijalkowski
2023-09-04 18:18 ` Larysa Zaremba
2023-09-14 16:25 ` [xdp-hints] " Alexander Lobakin
2023-09-14 16:28 ` Larysa Zaremba
2023-09-14 16:38 ` Alexander Lobakin
2023-09-14 17:02 ` Larysa Zaremba
2023-09-18 14:07 ` Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 11/23] ice: use VLAN proto from ring packet context in skb path Larysa Zaremba
2023-09-14 16:30 ` Alexander Lobakin
2023-09-14 16:30 ` Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 12/23] xdp: Add checksum hint Larysa Zaremba
2023-08-24 22:56 ` kernel test robot
2023-09-14 16:34 ` Alexander Lobakin
2023-08-24 19:26 ` [RFC bpf-next 13/23] ice: Implement " Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 14/23] selftests/bpf: Allow VLAN packets in xdp_hw_metadata Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 15/23] net, xdp: allow metadata > 32 Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 16/23] selftests/bpf: Add flags and new hints to xdp_hw_metadata Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 17/23] veth: Implement VLAN tag and checksum XDP hint Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 18/23] net: make vlan_get_tag() return -ENODATA instead of -EINVAL Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 19/23] selftests/bpf: Use AF_INET for TX in xdp_metadata Larysa Zaremba
2023-08-24 19:26 ` [RFC bpf-next 20/23] selftests/bpf: Check VLAN tag and proto " Larysa Zaremba
2023-08-24 19:27 ` [RFC bpf-next 21/23] selftests/bpf: check checksum state " Larysa Zaremba
2023-08-24 19:27 ` [RFC bpf-next 22/23] mlx5: implement VLAN tag XDP hint Larysa Zaremba
2023-08-24 19:27 ` [RFC bpf-next 23/23] mlx5: implement RX checksum " Larysa Zaremba
2023-08-31 14:50 ` [RFC bpf-next 00/23] XDP metadata via kfuncs for ice + mlx5 Larysa Zaremba
2023-09-04 16:06 ` [xdp-hints] " Maciej Fijalkowski
2023-09-06 14:09 ` Larysa Zaremba
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=ZPhGRylHigicNNSv@lincoln \
--to=larysa.zaremba@intel.com \
--cc=alexandr.lobakin@intel.com \
--cc=alexei.starovoitov@gmail.com \
--cc=anatoly.burakov@intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=dsahern@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@gmail.com \
--cc=martin.lau@linux.dev \
--cc=mtahhan@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@mellanox.com \
--cc=sdf@google.com \
--cc=simon.horman@corigine.com \
--cc=song@kernel.org \
--cc=tariqt@mellanox.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
--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.