Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: "Drewek, Wojciech" <wojciech.drewek@intel.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>
Subject: Re: [Intel-wired-lan] [PATCH net-next 04/12] ice: Implement basic eswitch bridge setup
Date: Thu, 20 Apr 2023 18:51:56 +0200	[thread overview]
Message-ID: <16f12548-b35a-bcd4-5a80-2b7e7cecb994@intel.com> (raw)
In-Reply-To: <MW4PR11MB5776C7DDDB91DD98A960AD20FD639@MW4PR11MB5776.namprd11.prod.outlook.com>

From: Wojciech Drewek <wojciech.drewek@intel.com>
Date: Thu, 20 Apr 2023 11:54:15 +0200

> Thanks for review Olek!
> 
> Most of the comments sound reasonable to me (and I will include them) with some exceptions.

Anytime, it's always a pleasure to review your team's code :p

>>> +static struct ice_esw_br_port *
>>> +ice_eswitch_br_port_init(struct ice_esw_br *bridge)
>>> +{
>>> +	struct ice_esw_br_port *br_port;
>>> +
>>> +	br_port = kzalloc(sizeof(*br_port), GFP_KERNEL);
>>> +	if (!br_port)
>>> +		return ERR_PTR(-ENOMEM);
>>> +
>>> +	br_port->bridge = bridge;
>>
>> Since you always pass @bridge from the call site either way, does it
>> make sense to do that or you could just assign -> bridge on the call
>> sites after a successful allocation?
> 
> I could do that but I prefer to keep it this way.
> We have two types of ports and this function is generic, It setups
> things common for both types, including bridge ref.
> Are you ok with it? 

Yes, sure. I noticed after sending that keeping this function as it is
will be more consistent with another one, which is pretty similar. So
I'm taking my words back :D

[...]

>>> +struct ice_esw_br {
>>> +	struct ice_esw_br_offloads *br_offloads;
>>> +	int ifindex;
>>> +
>>> +	struct xarray ports;
>>
>> (not sure about this one, but potentially there can be a hole between
>>  those two)
> 
> Move ifindex at the end?

I think the compilers will align this struct to 8 bytes. I'd try moving
it to the end, but I think it will just convert hole into padding at the
end. Then there's no difference and it can stay where it is now.
Holes can be filled any time when we're adding new fields, so not a big
problem.

> 
>>
>>> +};
>>> +
>>> +struct ice_esw_br_offloads {
>>> +	struct ice_pf *pf;
>>> +	struct ice_esw_br *bridge;
>>> +	struct notifier_block netdev_nb;
>>> +};
>>> +
>>> +#define ice_nb_to_br_offloads(nb, nb_name) \
>>> +	container_of(nb, \
>>> +		     struct ice_esw_br_offloads, \
>>> +		     nb_name)
>>
>> Hmm, you use it only once and only with `netdev_nb` field. Do you plan
>> to add more call sites of this macro? Otherwise you could embed the
>> second argument into the macro itself (mentioned `netdev_nb`) or even
>> just open-code the whole macro in the sole call site.
> 
> I the next patch it is used with different nb_name (switchdev_nb)

I noticed that, but only after reviewing the next patch, so sorry, this
one is closed :D

> 
>>
>>> +
>>> +void
>>> +ice_eswitch_br_offloads_deinit(struct ice_pf *pf);
>>> +int
>>> +ice_eswitch_br_offloads_init(struct ice_pf *pf);
>>> +
>>> +#endif /* _ICE_ESWITCH_BR_H_ */
>> [...]
>>
>> Thanks,
>> Olek

Thanks,
Olek
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  parent reply	other threads:[~2023-04-20 16:53 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-17  9:34 [Intel-wired-lan] [PATCH net-next 00/12] ice: switchdev bridge offload Wojciech Drewek
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 01/12] ice: Minor switchdev fixes Wojciech Drewek
2023-04-19 14:35   ` Alexander Lobakin
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 02/12] ice: Remove exclusion code for RDMA+SRIOV Wojciech Drewek
2023-04-19 14:38   ` Alexander Lobakin
2023-04-25 15:26   ` Michal Schmidt
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 03/12] ice: Unset src prune on uplink VSI Wojciech Drewek
2023-04-19 14:49   ` Alexander Lobakin
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 04/12] ice: Implement basic eswitch bridge setup Wojciech Drewek
2023-04-19 15:23   ` Alexander Lobakin
2023-04-20  9:54     ` Drewek, Wojciech
2023-04-20 10:46       ` Drewek, Wojciech
2023-04-20 16:53         ` Alexander Lobakin
2023-04-20 16:51       ` Alexander Lobakin [this message]
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 05/12] ice: Switchdev FDB events support Wojciech Drewek
2023-04-19 15:38   ` Alexander Lobakin
2023-04-20 11:27     ` Drewek, Wojciech
2023-04-20 16:59       ` Alexander Lobakin
2023-04-21  8:45         ` Drewek, Wojciech
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 06/12] ice: Add guard rule when creating FDB in switchdev Wojciech Drewek
2023-04-21 14:22   ` Alexander Lobakin
2023-04-25  9:17     ` Drewek, Wojciech
2023-04-26  9:50       ` Drewek, Wojciech
2023-04-26 15:24         ` Alexander Lobakin
2023-04-27  7:24           ` Drewek, Wojciech
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 07/12] ice: Accept LAG netdevs in bridge offloads Wojciech Drewek
2023-04-21 14:40   ` Alexander Lobakin
2023-04-26 11:31     ` Drewek, Wojciech
2023-04-26 15:31       ` Alexander Lobakin
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 08/12] ice: Add VLAN FDB support in switchdev mode Wojciech Drewek
2023-04-21 15:25   ` Alexander Lobakin
2023-04-27 10:28     ` Drewek, Wojciech
2023-05-08 14:09       ` Alexander Lobakin
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 09/12] ice: implement bridge port vlan Wojciech Drewek
2023-04-21 16:35   ` Alexander Lobakin
2023-05-09 11:25     ` Drewek, Wojciech
2023-05-09 15:06       ` Alexander Lobakin
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 10/12] ice: implement static version of ageing Wojciech Drewek
2023-04-21 16:22   ` Alexander Lobakin
2023-05-09 10:55     ` Drewek, Wojciech
2023-05-09 14:55       ` Alexander Lobakin
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 11/12] ice: add tracepoints for the switchdev bridge Wojciech Drewek
2023-04-17  9:34 ` [Intel-wired-lan] [PATCH net-next 12/12] ice: Ethtool fdb_cnt stats Wojciech Drewek
2023-04-21 16:32   ` Alexander Lobakin
2023-05-09 12:52     ` Drewek, Wojciech
2023-05-09 15:14       ` Alexander Lobakin

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=16f12548-b35a-bcd4-5a80-2b7e7cecb994@intel.com \
    --to=aleksander.lobakin@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=netdev@vger.kernel.org \
    --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