From: Alan Brady <alan.brady@intel.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: netdev@vger.kernel.org, Joshua Hay <joshua.a.hay@intel.com>,
intel-wired-lan@lists.osuosl.org,
Igor Bagnucki <igor.bagnucki@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH v5 01/10 iwl-next] idpf: implement virtchnl transaction manager
Date: Thu, 22 Feb 2024 06:35:26 -0800 [thread overview]
Message-ID: <39ab0807-468c-438a-bf56-7dd1298fecc4@intel.com> (raw)
In-Reply-To: <9f4d0449-9995-4bb0-bd95-f12d9bc0b234@intel.com>
On 2/22/2024 5:04 AM, Alexander Lobakin wrote:
> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> Date: Thu, 22 Feb 2024 13:53:25 +0100
>
>> From: Alan Brady <alan.brady@intel.com>
>> Date: Wed, 21 Feb 2024 12:16:37 -0800
>>
>>> On 2/21/2024 4:15 AM, Alexander Lobakin wrote:
>>>> From: Alan Brady <alan.brady@intel.com>
>>>> Date: Tue, 20 Feb 2024 16:49:40 -0800
>>>>
>>>>> This starts refactoring how virtchnl messages are handled by adding a
>>>>> transaction manager (idpf_vc_xn_manager).
>>
>> [...]
>>
>>>>
>>>> Sorry for not noticing this before, but this struct can be local to
>>>> idpf_virtchnl.c.
>>>>
>>>
>>> Nice catch, I can definitely move this. I'm also considering though, all
>>> of these structs I'm adding here are better suited in idpf_virtchnl.c
>>> all together. I think the main thing preventing that is the
>>> idpf_vc_xn_manager field in idpf_adapter. Would it be overkill to make
>>> the field in idpf_adapter a pointer so I can forward declare and kalloc
>>> it? I think I can then move everything to idpf_virtchnl.c. Or do you see
>>> a better alternative? Or is it not worth the effort? Thanks!
>>
>> Since it's not hotpath, you can make it a pointer and move everything to
>> virtchnl.c, sounds nice.
>
> Since you're sending v6 anyway, could you maybe move virtchnl function
> declarations to new idpf_virtchnl.h to make idpf.h a bit less heavy?
> Something like I did in this commit[0].
>
I can certainly do that as well, makes sense to me. I agree idpf.h is
overloaded. Thanks!
>>
>>>
>>>>> +
>>>>> +/**
>>>>> + * struct idpf_vc_xn_manager - Manager for tracking transactions
>>>>> + * @ring: backing and lookup for transactions
>>>>> + * @free_xn_bm: bitmap for free transactions
>>>>> + * @xn_bm_lock: make bitmap access synchronous where necessary
>>>>> + * @salt: used to make cookie unique every message
>>>>> + */
>>>>
>>>> [...]
>
> [0]
> https://github.com/alobakin/linux/commit/0c8fae557f4e6ec1ae4353a68c9c5c9c2b70c5e9
>
> Thanks,
> Olek
WARNING: multiple messages have this Message-ID (diff)
From: Alan Brady <alan.brady@intel.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: <intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>,
"Przemek Kitszel" <przemyslaw.kitszel@intel.com>,
Igor Bagnucki <igor.bagnucki@intel.com>,
Joshua Hay <joshua.a.hay@intel.com>
Subject: Re: [PATCH v5 01/10 iwl-next] idpf: implement virtchnl transaction manager
Date: Thu, 22 Feb 2024 06:35:26 -0800 [thread overview]
Message-ID: <39ab0807-468c-438a-bf56-7dd1298fecc4@intel.com> (raw)
In-Reply-To: <9f4d0449-9995-4bb0-bd95-f12d9bc0b234@intel.com>
On 2/22/2024 5:04 AM, Alexander Lobakin wrote:
> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> Date: Thu, 22 Feb 2024 13:53:25 +0100
>
>> From: Alan Brady <alan.brady@intel.com>
>> Date: Wed, 21 Feb 2024 12:16:37 -0800
>>
>>> On 2/21/2024 4:15 AM, Alexander Lobakin wrote:
>>>> From: Alan Brady <alan.brady@intel.com>
>>>> Date: Tue, 20 Feb 2024 16:49:40 -0800
>>>>
>>>>> This starts refactoring how virtchnl messages are handled by adding a
>>>>> transaction manager (idpf_vc_xn_manager).
>>
>> [...]
>>
>>>>
>>>> Sorry for not noticing this before, but this struct can be local to
>>>> idpf_virtchnl.c.
>>>>
>>>
>>> Nice catch, I can definitely move this. I'm also considering though, all
>>> of these structs I'm adding here are better suited in idpf_virtchnl.c
>>> all together. I think the main thing preventing that is the
>>> idpf_vc_xn_manager field in idpf_adapter. Would it be overkill to make
>>> the field in idpf_adapter a pointer so I can forward declare and kalloc
>>> it? I think I can then move everything to idpf_virtchnl.c. Or do you see
>>> a better alternative? Or is it not worth the effort? Thanks!
>>
>> Since it's not hotpath, you can make it a pointer and move everything to
>> virtchnl.c, sounds nice.
>
> Since you're sending v6 anyway, could you maybe move virtchnl function
> declarations to new idpf_virtchnl.h to make idpf.h a bit less heavy?
> Something like I did in this commit[0].
>
I can certainly do that as well, makes sense to me. I agree idpf.h is
overloaded. Thanks!
>>
>>>
>>>>> +
>>>>> +/**
>>>>> + * struct idpf_vc_xn_manager - Manager for tracking transactions
>>>>> + * @ring: backing and lookup for transactions
>>>>> + * @free_xn_bm: bitmap for free transactions
>>>>> + * @xn_bm_lock: make bitmap access synchronous where necessary
>>>>> + * @salt: used to make cookie unique every message
>>>>> + */
>>>>
>>>> [...]
>
> [0]
> https://github.com/alobakin/linux/commit/0c8fae557f4e6ec1ae4353a68c9c5c9c2b70c5e9
>
> Thanks,
> Olek
next prev parent reply other threads:[~2024-02-22 14:35 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-21 0:49 [Intel-wired-lan] [PATCH v5 00/10 iwl-next] idpf: refactor virtchnl messages Alan Brady
2024-02-21 0:49 ` Alan Brady
2024-02-21 0:49 ` [Intel-wired-lan] [PATCH v5 01/10 iwl-next] idpf: implement virtchnl transaction manager Alan Brady
2024-02-21 0:49 ` Alan Brady
2024-02-21 12:15 ` [Intel-wired-lan] " Alexander Lobakin
2024-02-21 12:15 ` Alexander Lobakin
2024-02-21 20:16 ` [Intel-wired-lan] " Alan Brady
2024-02-21 20:16 ` Alan Brady
2024-02-22 12:53 ` [Intel-wired-lan] " Alexander Lobakin
2024-02-22 12:53 ` Alexander Lobakin
2024-02-22 13:04 ` [Intel-wired-lan] " Alexander Lobakin
2024-02-22 13:04 ` Alexander Lobakin
2024-02-22 14:35 ` Alan Brady [this message]
2024-02-22 14:35 ` Alan Brady
2024-02-21 0:49 ` [Intel-wired-lan] [PATCH v5 02/10 iwl-next] idpf: refactor vport virtchnl messages Alan Brady
2024-02-21 0:49 ` Alan Brady
2024-02-21 0:49 ` [Intel-wired-lan] [PATCH v5 03/10 iwl-next] idpf: refactor queue related " Alan Brady
2024-02-21 0:49 ` Alan Brady
2024-02-21 0:49 ` [Intel-wired-lan] [PATCH v5 04/10 iwl-next] idpf: refactor remaining " Alan Brady
2024-02-21 0:49 ` Alan Brady
2024-02-21 0:49 ` [Intel-wired-lan] [PATCH v5 05/10 iwl-next] idpf: add async_handler for MAC filter messages Alan Brady
2024-02-21 0:49 ` Alan Brady
2024-02-21 0:49 ` [Intel-wired-lan] [PATCH v5 06/10 iwl-next] idpf: refactor idpf_recv_mb_msg Alan Brady
2024-02-21 0:49 ` Alan Brady
2024-02-21 0:49 ` [Intel-wired-lan] [PATCH v5 07/10 iwl-next] idpf: cleanup virtchnl cruft Alan Brady
2024-02-21 0:49 ` Alan Brady
2024-02-21 0:49 ` [Intel-wired-lan] [PATCH v5 08/10 iwl-next] idpf: prevent deinit uninitialized virtchnl core Alan Brady
2024-02-21 0:49 ` Alan Brady
2024-02-21 0:49 ` [Intel-wired-lan] [PATCH v5 09/10 iwl-next] idpf: fix minor controlq issues Alan Brady
2024-02-21 0:49 ` Alan Brady
2024-02-21 0:49 ` [Intel-wired-lan] [PATCH v5 10/10 iwl-next] idpf: remove dealloc vector msg err in idpf_intr_rel Alan Brady
2024-02-21 0:49 ` Alan Brady
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=39ab0807-468c-438a-bf56-7dd1298fecc4@intel.com \
--to=alan.brady@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=igor.bagnucki@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=joshua.a.hay@intel.com \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@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 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.