[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MW4PR11MB59112303C2327179D3BE63CDBA5D2@MW4PR11MB5911.namprd11.prod.outlook.com>
Date: Sat, 2 Mar 2024 04:33:19 +0000
From: "Singh, Krishneil K" <krishneil.k.singh@...el.com>
To: "Brady, Alan" <alan.brady@...el.com>, "intel-wired-lan@...ts.osuosl.org"
<intel-wired-lan@...ts.osuosl.org>
CC: "Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>, "Hay, Joshua A"
<joshua.a.hay@...el.com>, "Lobakin, Aleksander"
<aleksander.lobakin@...el.com>, "Brady, Alan" <alan.brady@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Bagnucki, Igor"
<igor.bagnucki@...el.com>
Subject: RE: [Intel-wired-lan] [PATCH v6 02/11 iwl-next] idpf: implement
virtchnl transaction manager
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of
> Alan Brady
> Sent: Thursday, February 22, 2024 11:05 AM
> To: intel-wired-lan@...ts.osuosl.org
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@...el.com>; Hay, Joshua A
> <joshua.a.hay@...el.com>; Lobakin, Aleksander
> <aleksander.lobakin@...el.com>; Brady, Alan <alan.brady@...el.com>;
> netdev@...r.kernel.org; Bagnucki, Igor <igor.bagnucki@...el.com>
> Subject: [Intel-wired-lan] [PATCH v6 02/11 iwl-next] idpf: implement virtchnl
> transaction manager
>
> This starts refactoring how virtchnl messages are handled by adding a
> transaction manager (idpf_vc_xn_manager).
>
> There are two primary motivations here which are to enable handling of
> multiple messages at once and to make it more robust in general. As it
> is right now, the driver may only have one pending message at a time and
> there's no guarantee that the response we receive was actually intended
> for the message we sent prior.
>
> This works by utilizing a "cookie" field of the message descriptor. It
> is arbitrary what data we put in the cookie and the response is required
> to have the same cookie the original message was sent with. Then using a
> "transaction" abstraction that uses the completion API to pair responses
> to the message it belongs to.
>
> The cookie works such that the first half is the index to the
> transaction in our array, and the second half is a "salt" that gets
> incremented every message. This enables quick lookups into the array and
> also ensuring we have the correct message. The salt is necessary because
> after, for example, a message times out and we deem the response was
> lost for some reason, we could theoretically reuse the same index but
> using a different salt ensures that when we do actually get a response
> it's not the old message that timed out previously finally coming in.
> Since the number of transactions allocated is U8_MAX and the salt is 8
> bits, we can never have a conflict because we can't roll over the salt
> without using more transactions than we have available.
>
> This starts by only converting the VIRTCHNL2_OP_VERSION message to use
> this new transaction API. Follow up patches will convert all virtchnl
> messages to use the API.
>
> Tested-by: Alexander Lobakin <aleksander.lobakin@...el.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
> Reviewed-by: Igor Bagnucki <igor.bagnucki@...el.com>
> Co-developed-by: Joshua Hay <joshua.a.hay@...el.com>
> Signed-off-by: Joshua Hay <joshua.a.hay@...el.com>
> Signed-off-by: Alan Brady <alan.brady@...el.com>
> ---
> drivers/net/ethernet/intel/idpf/idpf.h | 6 +-
> .../ethernet/intel/idpf/idpf_controlq_api.h | 5 +
> drivers/net/ethernet/intel/idpf/idpf_lib.c | 2 +
> drivers/net/ethernet/intel/idpf/idpf_main.c | 3 +
> drivers/net/ethernet/intel/idpf/idpf_vf_dev.c | 2 +-
> .../net/ethernet/intel/idpf/idpf_virtchnl.c | 614 ++++++++++++++++--
> .../net/ethernet/intel/idpf/idpf_virtchnl.h | 2 +-
> 7 files changed, 561 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf.h
> b/drivers/net/ethernet/intel/idpf/idpf.h
> index b2f1bc63c3b6..c3b08d4593b0 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf.h
> +++ b/drivers/net/ethernet/intel/idpf/idpf.h
Tested-by: Krishneil Singh <krishneil.k.singh@...el.com>
Powered by blists - more mailing lists