public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Cc: <intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>,
	<wojciech.drewek@intel.com>, <piotr.raczynski@intel.com>,
	<pmenzel@molgen.mpg.de>
Subject: Re: [PATCH net-next v3 4/5] ice: specify field names in ice_prot_ext init
Date: Wed, 5 Apr 2023 15:25:53 +0200	[thread overview]
Message-ID: <68714dbe-3a43-9e3a-2bb5-8f1659b4a979@intel.com> (raw)
In-Reply-To: <20230405075113.455662-5-michal.swiatkowski@linux.intel.com>

From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Date: Wed, 5 Apr 2023 09:51:12 +0200

> Anonymous initializers are now discouraged. Define ICE_PROTCOL_ENTRY
> macro to rewrite anonymous initializers to named one. No functional
> changes here.
> 
> Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_switch.c | 68 +++++++++++----------
>  1 file changed, 36 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
> index b55cdb9a009f..8872e26d1368 100644
> --- a/drivers/net/ethernet/intel/ice/ice_switch.c
> +++ b/drivers/net/ethernet/intel/ice/ice_switch.c
> @@ -4540,6 +4540,11 @@ ice_free_res_cntr(struct ice_hw *hw, u8 type, u8 alloc_shared, u16 num_items,
>  	return status;
>  }
>  
> +#define ICE_PROTOCOL_ENTRY(id, ...) {	\
> +	.prot_type = id,		\
> +	.offs	   = {__VA_ARGS__},	\

Minor: please use one tab in between field name and `=` sign (you have
spaces there for now).

> +}
> +
>  /* This is mapping table entry that maps every word within a given protocol
>   * structure to the real byte offset as per the specification of that
>   * protocol header.
> @@ -4550,38 +4555,37 @@ ice_free_res_cntr(struct ice_hw *hw, u8 type, u8 alloc_shared, u16 num_items,
>   * structure is added to that union.
>   */
>  static const struct ice_prot_ext_tbl_entry ice_prot_ext[ICE_PROTOCOL_LAST] = {
> -	{ ICE_MAC_OFOS,		{ 0, 2, 4, 6, 8, 10, 12 } },
> -	{ ICE_MAC_IL,		{ 0, 2, 4, 6, 8, 10, 12 } },
> -	{ ICE_ETYPE_OL,		{ 0 } },
> -	{ ICE_ETYPE_IL,		{ 0 } },
> -	{ ICE_VLAN_OFOS,	{ 2, 0 } },
> -	{ ICE_IPV4_OFOS,	{ 0, 2, 4, 6, 8, 10, 12, 14, 16, 18 } },
> -	{ ICE_IPV4_IL,		{ 0, 2, 4, 6, 8, 10, 12, 14, 16, 18 } },
> -	{ ICE_IPV6_OFOS,	{ 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24,
> -				 26, 28, 30, 32, 34, 36, 38 } },
> -	{ ICE_IPV6_IL,		{ 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24,
> -				 26, 28, 30, 32, 34, 36, 38 } },
> -	{ ICE_TCP_IL,		{ 0, 2 } },
> -	{ ICE_UDP_OF,		{ 0, 2 } },
> -	{ ICE_UDP_ILOS,		{ 0, 2 } },
> -	{ ICE_VXLAN,		{ 8, 10, 12, 14 } },
> -	{ ICE_GENEVE,		{ 8, 10, 12, 14 } },
> -	{ ICE_NVGRE,		{ 0, 2, 4, 6 } },
> -	{ ICE_GTP,		{ 8, 10, 12, 14, 16, 18, 20, 22 } },
> -	{ ICE_GTP_NO_PAY,	{ 8, 10, 12, 14 } },
> -	{ ICE_PPPOE,		{ 0, 2, 4, 6 } },
> -	{ ICE_L2TPV3,		{ 0, 2, 4, 6, 8, 10 } },
> -	{ ICE_VLAN_EX,          { 2, 0 } },
> -	{ ICE_VLAN_IN,          { 2, 0 } },
> -	{ ICE_HW_METADATA,	{ ICE_SOURCE_PORT_MDID_OFFSET,
> -				  ICE_PTYPE_MDID_OFFSET,
> -				  ICE_PACKET_LENGTH_MDID_OFFSET,
> -				  ICE_SOURCE_VSI_MDID_OFFSET,
> -				  ICE_PKT_VLAN_MDID_OFFSET,
> -				  ICE_PKT_TUNNEL_MDID_OFFSET,
> -				  ICE_PKT_TCP_MDID_OFFSET,
> -				  ICE_PKT_ERROR_MDID_OFFSET,
> -				}},
> +	ICE_PROTOCOL_ENTRY(ICE_MAC_OFOS, 0, 2, 4, 6, 8, 10, 12),
> +	ICE_PROTOCOL_ENTRY(ICE_MAC_IL, 0, 2, 4, 6, 8, 10, 12),
> +	ICE_PROTOCOL_ENTRY(ICE_ETYPE_OL, 0),
> +	ICE_PROTOCOL_ENTRY(ICE_ETYPE_IL, 0),

BTW, as offset arguments go into the array declaration, you can even
omit such single-zero-element declarations. I.e., if I'm not mistaken,
these two equal to just:

	ICE_PROTOCOL_ENTRY(ICE_ETYPE_OL),
	ICE_PROTOCOL_ENTRY(ICE_ETYPE_IL),

But: 1) better to recheck; 2) up to you, maybe it's better to explicitly
mention zero offsets here.

> +	ICE_PROTOCOL_ENTRY(ICE_VLAN_OFOS, 2, 0),
> +	ICE_PROTOCOL_ENTRY(ICE_IPV4_OFOS, 0, 2, 4, 6, 8, 10, 12, 14, 16, 18),
> +	ICE_PROTOCOL_ENTRY(ICE_IPV4_IL,	0, 2, 4, 6, 8, 10, 12, 14, 16, 18),
> +	ICE_PROTOCOL_ENTRY(ICE_IPV6_OFOS, 0, 2, 4, 6, 8, 10, 12, 14, 16, 18,
> +			   20, 22, 24, 26, 28, 30, 32, 34, 36, 38),
> +	ICE_PROTOCOL_ENTRY(ICE_IPV6_IL, 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20,
> +			   22, 24, 26, 28, 30, 32, 34, 36, 38),
> +	ICE_PROTOCOL_ENTRY(ICE_TCP_IL, 0, 2),
> +	ICE_PROTOCOL_ENTRY(ICE_UDP_OF, 0, 2),
> +	ICE_PROTOCOL_ENTRY(ICE_UDP_ILOS, 0, 2),
> +	ICE_PROTOCOL_ENTRY(ICE_VXLAN, 8, 10, 12, 14),
> +	ICE_PROTOCOL_ENTRY(ICE_GENEVE, 8, 10, 12, 14),
> +	ICE_PROTOCOL_ENTRY(ICE_NVGRE, 0, 2, 4, 6),
> +	ICE_PROTOCOL_ENTRY(ICE_GTP, 8, 10, 12, 14, 16, 18, 20, 22),
> +	ICE_PROTOCOL_ENTRY(ICE_GTP_NO_PAY, 8, 10, 12, 14),
> +	ICE_PROTOCOL_ENTRY(ICE_PPPOE, 0, 2, 4, 6),
> +	ICE_PROTOCOL_ENTRY(ICE_L2TPV3, 0, 2, 4, 6, 8, 10),
> +	ICE_PROTOCOL_ENTRY(ICE_VLAN_EX, 2, 0),
> +	ICE_PROTOCOL_ENTRY(ICE_VLAN_IN, 2, 0),
> +	ICE_PROTOCOL_ENTRY(ICE_HW_METADATA, ICE_SOURCE_PORT_MDID_OFFSET,

Nit: I think here's the exceptional case when you can specify this
second argument on the next line, i.e. break the line even though it
fits into 80 chars. This looks a bit off to me :D

> +			   ICE_PTYPE_MDID_OFFSET,
> +			   ICE_PACKET_LENGTH_MDID_OFFSET,
> +			   ICE_SOURCE_VSI_MDID_OFFSET,
> +			   ICE_PKT_VLAN_MDID_OFFSET,
> +			   ICE_PKT_TUNNEL_MDID_OFFSET,
> +			   ICE_PKT_TCP_MDID_OFFSET,
> +			   ICE_PKT_ERROR_MDID_OFFSET),

Hmm, could this patch go as 3/5, i.e. before this last element is
introduced, so that there'll be 16 lines less in diffstat?

>  };
>  
>  static struct ice_protocol_entry ice_prot_id_tbl[ICE_PROTOCOL_LAST] = {

Thanks,
Olek

  reply	other threads:[~2023-04-05 13:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05  7:51 [PATCH net-next v3 0/5] ice: allow matching on meta data Michal Swiatkowski
2023-04-05  7:51 ` [PATCH net-next v3 1/5] ice: define meta data to match in switch Michal Swiatkowski
2023-04-05  7:51 ` [PATCH net-next v3 2/5] ice: remove redundant Rx field from rule info Michal Swiatkowski
2023-04-05  7:51 ` [PATCH net-next v3 3/5] ice: allow matching on meta data Michal Swiatkowski
2023-04-05 13:31   ` Alexander Lobakin
2023-04-06 11:32     ` Michal Swiatkowski
2023-04-05  7:51 ` [PATCH net-next v3 4/5] ice: specify field names in ice_prot_ext init Michal Swiatkowski
2023-04-05 13:25   ` Alexander Lobakin [this message]
2023-04-06 11:34     ` Michal Swiatkowski
2023-04-05  7:51 ` [PATCH net-next v3 5/5] ice: use src VSI instead of src MAC in slow-path Michal Swiatkowski

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=68714dbe-3a43-9e3a-2bb5-8f1659b4a979@intel.com \
    --to=aleksander.lobakin@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=michal.swiatkowski@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=piotr.raczynski@intel.com \
    --cc=pmenzel@molgen.mpg.de \
    --cc=wojciech.drewek@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox