From: Simon Horman <horms@kernel.org>
To: Milena Olech <milena.olech@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
Josh Hay <joshua.a.hay@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH v4 iwl-next 08/10] idpf: add Tx timestamp flows
Date: Tue, 14 Jan 2025 16:26:48 +0000 [thread overview]
Message-ID: <20250114162648.GK5497@kernel.org> (raw)
In-Reply-To: <20250114121103.605288-9-milena.olech@intel.com>
On Tue, Jan 14, 2025 at 01:11:13PM +0100, Milena Olech wrote:
> Add functions to request Tx timestamp for the PTP packets, read the Tx
> timestamp when the completion tag for that packet is being received,
> extend the Tx timestamp value and set the supported timestamping modes.
>
> Tx timestamp is requested for the PTP packets by setting a TSYN bit and
> index value in the Tx context descriptor. The driver assumption is that
> the Tx timestamp value is ready to be read when the completion tag is
> received. Then the driver schedules delayed work and the Tx timestamp
> value read is requested through virtchnl message. At the end, the Tx
> timestamp value is extended to 64-bit and provided back to the skb.
>
> Co-developed-by: Josh Hay <joshua.a.hay@intel.com>
> Signed-off-by: Josh Hay <joshua.a.hay@intel.com>
> Signed-off-by: Milena Olech <milena.olech@intel.com>
...
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_ptp.c b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
...
> +/**
> + * idpf_ptp_request_ts - Request an available Tx timestamp index
> + * @tx_q: Transmit queue on which the Tx timestamp is requested
> + * @skb: The SKB to associate with this timestamp request
> + * @idx: Index of the Tx timestamp latch
> + *
> + * Request tx timestamp index negotiated during PTP init that will be set into
> + * Tx descriptor.
> + *
> + * Return: 0 and the index that can be provided to Tx descriptor on success,
> + * -errno otherwise.
> + */
> +int idpf_ptp_request_ts(struct idpf_tx_queue *tx_q, struct sk_buff *skb,
> + u32 *idx)
> +{
> + struct idpf_ptp_tx_tstamp *ptp_tx_tstamp;
> + struct list_head *head;
> +
> + /* Get the index from the free latches list */
> + spin_lock_bh(&tx_q->cached_tstamp_caps->lock_free);
> +
> + head = &tx_q->cached_tstamp_caps->latches_free;
> + if (list_empty(head)) {
> + spin_unlock_bh(&tx_q->cached_tstamp_caps->lock_in_use);
Hi Milena and Josh,
Should the line above be:
spin_unlock_bh(&tx_q->cached_tstamp_caps->lock_free);
^^^^^^^^^
Flagged by Smatch.
> + return -ENOBUFS;
> + }
> +
> + ptp_tx_tstamp = list_first_entry(head, struct idpf_ptp_tx_tstamp,
> + list_member);
> + list_del(&ptp_tx_tstamp->list_member);
> + spin_unlock_bh(&tx_q->cached_tstamp_caps->lock_free);
> +
> + ptp_tx_tstamp->skb = skb_get(skb);
> + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
> +
> + /* Move the element to the used latches list */
> + spin_lock_bh(&tx_q->cached_tstamp_caps->lock_in_use);
> + list_add(&ptp_tx_tstamp->list_member,
> + &tx_q->cached_tstamp_caps->latches_in_use);
> + spin_unlock_bh(&tx_q->cached_tstamp_caps->lock_in_use);
> +
> + *idx = ptp_tx_tstamp->idx;
> +
> + return 0;
> +}
...
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Milena Olech <milena.olech@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
Josh Hay <joshua.a.hay@intel.com>
Subject: Re: [PATCH v4 iwl-next 08/10] idpf: add Tx timestamp flows
Date: Tue, 14 Jan 2025 16:26:48 +0000 [thread overview]
Message-ID: <20250114162648.GK5497@kernel.org> (raw)
In-Reply-To: <20250114121103.605288-9-milena.olech@intel.com>
On Tue, Jan 14, 2025 at 01:11:13PM +0100, Milena Olech wrote:
> Add functions to request Tx timestamp for the PTP packets, read the Tx
> timestamp when the completion tag for that packet is being received,
> extend the Tx timestamp value and set the supported timestamping modes.
>
> Tx timestamp is requested for the PTP packets by setting a TSYN bit and
> index value in the Tx context descriptor. The driver assumption is that
> the Tx timestamp value is ready to be read when the completion tag is
> received. Then the driver schedules delayed work and the Tx timestamp
> value read is requested through virtchnl message. At the end, the Tx
> timestamp value is extended to 64-bit and provided back to the skb.
>
> Co-developed-by: Josh Hay <joshua.a.hay@intel.com>
> Signed-off-by: Josh Hay <joshua.a.hay@intel.com>
> Signed-off-by: Milena Olech <milena.olech@intel.com>
...
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_ptp.c b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
...
> +/**
> + * idpf_ptp_request_ts - Request an available Tx timestamp index
> + * @tx_q: Transmit queue on which the Tx timestamp is requested
> + * @skb: The SKB to associate with this timestamp request
> + * @idx: Index of the Tx timestamp latch
> + *
> + * Request tx timestamp index negotiated during PTP init that will be set into
> + * Tx descriptor.
> + *
> + * Return: 0 and the index that can be provided to Tx descriptor on success,
> + * -errno otherwise.
> + */
> +int idpf_ptp_request_ts(struct idpf_tx_queue *tx_q, struct sk_buff *skb,
> + u32 *idx)
> +{
> + struct idpf_ptp_tx_tstamp *ptp_tx_tstamp;
> + struct list_head *head;
> +
> + /* Get the index from the free latches list */
> + spin_lock_bh(&tx_q->cached_tstamp_caps->lock_free);
> +
> + head = &tx_q->cached_tstamp_caps->latches_free;
> + if (list_empty(head)) {
> + spin_unlock_bh(&tx_q->cached_tstamp_caps->lock_in_use);
Hi Milena and Josh,
Should the line above be:
spin_unlock_bh(&tx_q->cached_tstamp_caps->lock_free);
^^^^^^^^^
Flagged by Smatch.
> + return -ENOBUFS;
> + }
> +
> + ptp_tx_tstamp = list_first_entry(head, struct idpf_ptp_tx_tstamp,
> + list_member);
> + list_del(&ptp_tx_tstamp->list_member);
> + spin_unlock_bh(&tx_q->cached_tstamp_caps->lock_free);
> +
> + ptp_tx_tstamp->skb = skb_get(skb);
> + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
> +
> + /* Move the element to the used latches list */
> + spin_lock_bh(&tx_q->cached_tstamp_caps->lock_in_use);
> + list_add(&ptp_tx_tstamp->list_member,
> + &tx_q->cached_tstamp_caps->latches_in_use);
> + spin_unlock_bh(&tx_q->cached_tstamp_caps->lock_in_use);
> +
> + *idx = ptp_tx_tstamp->idx;
> +
> + return 0;
> +}
...
next prev parent reply other threads:[~2025-01-14 16:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-14 12:10 [Intel-wired-lan] [PATCH v4 iwl-next 00/10] idpf: add initial PTP support Milena Olech
2025-01-14 12:10 ` Milena Olech
2025-01-14 12:10 ` [Intel-wired-lan] [PATCH v4 iwl-next 01/10] " Milena Olech
2025-01-14 12:10 ` Milena Olech
2025-01-14 12:11 ` [Intel-wired-lan] [PATCH v4 iwl-next 02/10] virtchnl: add PTP virtchnl definitions Milena Olech
2025-01-14 12:11 ` Milena Olech
2025-01-14 12:11 ` [Intel-wired-lan] [PATCH v4 iwl-next 03/10] idpf: move virtchnl structures to the header file Milena Olech
2025-01-14 12:11 ` Milena Olech
2025-01-14 12:11 ` [Intel-wired-lan] [PATCH v4 iwl-next 04/10] idpf: negotiate PTP capabilities and get PTP clock Milena Olech
2025-01-14 12:11 ` Milena Olech
2025-01-14 12:11 ` [Intel-wired-lan] [PATCH v4 iwl-next 05/10] idpf: add mailbox access to read PTP clock time Milena Olech
2025-01-14 12:11 ` Milena Olech
2025-01-14 12:11 ` [Intel-wired-lan] [PATCH v4 iwl-next 06/10] idpf: add PTP clock configuration Milena Olech
2025-01-14 12:11 ` Milena Olech
2025-01-14 12:11 ` [Intel-wired-lan] [PATCH v4 iwl-next 07/10] idpf: add Tx timestamp capabilities negotiation Milena Olech
2025-01-14 12:11 ` Milena Olech
2025-01-14 12:11 ` [Intel-wired-lan] [PATCH v4 iwl-next 08/10] idpf: add Tx timestamp flows Milena Olech
2025-01-14 12:11 ` Milena Olech
2025-01-14 16:26 ` Simon Horman [this message]
2025-01-14 16:26 ` Simon Horman
2025-01-15 11:56 ` [Intel-wired-lan] " Olech, Milena
2025-01-15 11:56 ` Olech, Milena
2025-01-14 12:11 ` [Intel-wired-lan] [PATCH v4 iwl-next 09/10] idpf: add support for Rx timestamping Milena Olech
2025-01-14 12:11 ` Milena Olech
2025-01-14 12:11 ` [Intel-wired-lan] [PATCH v4 iwl-next 10/10] idpf: change the method for mailbox workqueue allocation Milena Olech
2025-01-14 12:11 ` Milena Olech
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=20250114162648.GK5497@kernel.org \
--to=horms@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=joshua.a.hay@intel.com \
--cc=milena.olech@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.