[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <086bf4f8-7a4c-4323-ae7a-c7c23223acec@intel.com>
Date: Tue, 30 Jul 2024 16:24:40 +0200
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Mateusz Polchlopek <mateusz.polchlopek@...el.com>
CC: <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v8 09/14] libeth: move
idpf_rx_csum_decoded and idpf_rx_extracted
From: Mateusz Polchlopek <mateusz.polchlopek@...el.com>
Date: Tue, 30 Jul 2024 05:15:04 -0400
> Structs idpf_rx_csum_decoded and idpf_rx_extracted are used both in
> idpf and iavf Intel drivers. This commit changes the prefix from
> idpf_* to libeth_* and moves mentioned structs to libeth's rx.h header
> file.
[...]
> diff --git a/include/net/libeth/rx.h b/include/net/libeth/rx.h
> index 43574bd6612f..197ff0f5e34c 100644
> --- a/include/net/libeth/rx.h
> +++ b/include/net/libeth/rx.h
> @@ -258,4 +258,38 @@ static inline void libeth_rx_pt_set_hash(struct sk_buff *skb, u32 hash,
> skb_set_hash(skb, hash, pt.payload_layer);
> }
>
> +/**
> + * struct libeth_rx_csum_decoded - csum errors indicators
1. I'd name it just 'libeth_rx_csum'.
2. The brief you put at the end of the doc can be moved here.
* struct libeth_rx_csum - Rx checksum offload status
> + * @l3l4p: L3 and L4 integrity check
What does it mean? kdoc should explain everything to help people understand.
>From this desc, I don't get whether it's a "valid checksum" status or
"invalid checksum" status. Whether it means that both L3 and L4 are
correct or can be only one of them?
> + * @ipe: IP checksum error indication
'indication' can be omitted. Just 'IP checksum error'.
> + * @eipe: External (most outer) IP header (only relevant for tunneled packets)
1. 'outermost'.
2. Please start each field's description from a lowercase letter.
* @eipe: external
...
3. 'only relevant for tunneled packets' can be just 'only for tunnels'
> + * @eudpe: External (most outer) UDP checksum error (only relevant for tunneled
> + * packets)
> + * @ipv6exadd: IPv6 with Destination Options Header or Routing Header
Maybe 'IPv6 header with extension headers'?
> + * @l4e: L4 integrity error indication
Same as for l3l4p.
> + *
> + * Checksum offload bits decoded from the receive descriptor.
> + */
> +struct libeth_rx_csum_decoded {
> + u32 l3l4p:1;
> + u32 ipe:1;
> + u32 eipe:1;
> + u32 eudpe:1;
> + u32 ipv6exadd:1;
> + u32 l4e:1;
> + u32 pprs:1;
> + u32 nat:1;
> + u32 raw_csum_inv:1;
> + u32 raw_csum:16;
> +};
1. Please place this struct (as well as the second one) after
&libeth_rx_pt and align the indentation to it (my style is
that I keep one indentation level per file).
3. You need a padding, so that ::raw_csum will be at offset of 2 bytes,
i.e. aligned naturally. See how I align ::hash type in &libeth_rx_pt.
I.e.
u32 raw_csum_inv:1;
u32 pad:7;
u32 raw_csum:16;
4. I'd invert ::raw_csum_inv to ::raw_csum_valid.
5. kernel-doc for each field is needed. Here a half of fields doesn't
have it.
scripts/kernel-doc -none -Wall include/net/libeth/rx.h
> +
> +struct libeth_rx_extracted {
The structure name says nothing.
Maybe
struct libeth_rqe_info {
"Receive queue element info".
I chose RQE, not "packet", as this info is per-descriptor, not
per-packet.
> + unsigned int size;
'len'?
> + u16 vlan_tag;
Is it C-Tag or S-Tag or both depending on something or...?
> + u16 rx_ptype;
Just 'ptype'?
> + u8 end_of_packet:1;
Just 'eop'?
> + u8 rxe:1;
> +};
1. kdoc. I've no idea what 'rxe' does mean.
2. Why `u8` and `u16`, but `unsigned int`, not `u32`?
(I'd make everything u32:bits BTW)
3. You waste 4 bytes for only 2 bits.
Since maximum ptype is currently 1024, while u16 can store up to
65535, you could do
struct libeth_rqe_info {
u32 len;
u32 vlan_tag:16;
u32 ptype:14;
u32 eop:1;
u32 rxe:1;
};
Most important: do you realize that not all of the fields are needed in
the same place, but some of them earlier, some later, and sometime not
even all of them are neede? For example, if it's not an EOP frag, you
would only need ::len and ::eop and that's it. The rest is only needed
for EOP fragments.
That means, reading all of them at once to one struct can lead to perf
regressions. One way to avoid this is to read-fields-when-needed, e.g.
always fill ::len and ::eop and the rest later if/when needed.
Also, can we just do a ptype lookup right away when we read ptype from
the descriptor and then pass &libeth_rx_pt everywhere, so that we won't
even need the ::ptype field here?
> +
> +
> #endif /* __LIBETH_RX_H */
Thanks,
Olek
Powered by blists - more mailing lists