linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, horms@kernel.org, saeedm@nvidia.com,
	anthony.l.nguyen@intel.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, corbet@lwn.net,
	linux-doc@vger.kernel.org, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, horatiu.vultur@microchip.com,
	ruanjinjie@huawei.com, steen.hegelund@microchip.com,
	vladimir.oltean@nxp.com, UNGLinuxDriver@microchip.com,
	Thorsten.Kummermehr@microchip.com, Pier.Beruto@onsemi.com,
	Selvamani.Rajagopal@onsemi.com, Nicolas.Ferre@microchip.com,
	benjamin.bigler@bernformulastudent.ch
Subject: Re: [PATCH net-next v3 08/12] net: ethernet: oa_tc6: implement transmit path to transfer tx ethernet frames
Date: Thu, 7 Mar 2024 18:08:52 +0100	[thread overview]
Message-ID: <208fb61b-4740-46bf-8c70-29ab59cbb965@lunn.ch> (raw)
In-Reply-To: <20240306085017.21731-9-Parthiban.Veerasooran@microchip.com>

> @@ -55,6 +77,14 @@
>  						(OA_TC6_CTRL_MAX_REGISTERS *\
>  						OA_TC6_CTRL_REG_VALUE_SIZE) +\
>  						OA_TC6_CTRL_IGNORED_SIZE)
> +#define OA_TC6_CHUNK_PAYLOAD_SIZE		64
> +#define OA_TC6_DATA_HEADER_SIZE			4
> +#define OA_TC6_CHUNK_SIZE			(OA_TC6_DATA_HEADER_SIZE +\
> +						OA_TC6_CHUNK_PAYLOAD_SIZE)
> +#define OA_TC6_TX_SKB_QUEUE_SIZE		100

So you keep up to 100 packets in a queue. If use assume typical MTU
size packets, that is 1,238,400 bits. At 10Mbps, that is 120ms of
traffic. That is quite a lot of latency when a high priority packet is
added to the tail of the queue and needs to wait for all the other
packets to be sent first.

Chunks are 64 bytes. So in practice, you only ever need two
packets. You need to be able to fill a chunk with the final part of
one packet, and the beginning of the next. So i would try using a much
smaller queue size. That will allow Linux queue disciplines to give
you the high priority packets first which you send with low latency.

> +static void oa_tc6_add_tx_skb_to_spi_buf(struct oa_tc6 *tc6)
> +{
> +	enum oa_tc6_data_start_valid_info start_valid = OA_TC6_DATA_START_INVALID;
> +	enum oa_tc6_data_end_valid_info end_valid = OA_TC6_DATA_END_INVALID;
> +	__be32 *tx_buf = tc6->spi_data_tx_buf + tc6->spi_data_tx_buf_offset;
> +	u16 remaining_length = tc6->tx_skb->len - tc6->tx_skb_offset;
> +	u8 *tx_skb_data = tc6->tx_skb->data + tc6->tx_skb_offset;
> +	u8 end_byte_offset = 0;
> +	u16 length_to_copy;
> +
> +	/* Set start valid if the current tx chunk contains the start of the tx
> +	 * ethernet frame.
> +	 */
> +	if (!tc6->tx_skb_offset)
> +		start_valid = OA_TC6_DATA_START_VALID;
> +
> +	/* If the remaining tx skb length is more than the chunk payload size of
> +	 * 64 bytes then copy only 64 bytes and leave the ongoing tx skb for
> +	 * next tx chunk.
> +	 */
> +	length_to_copy = min_t(u16, remaining_length, OA_TC6_CHUNK_PAYLOAD_SIZE);
> +
> +	/* Copy the tx skb data to the tx chunk payload buffer */
> +	memcpy(tx_buf + 1, tx_skb_data, length_to_copy);
> +	tc6->tx_skb_offset += length_to_copy;

You probably need a call to skb_linearize() somewhere. You assume the
packet data is contiguous. It can in fact be split into multiple
segments. skb_linearize() will convert it to a single buffer.

> +static int oa_tc6_try_spi_transfer(struct oa_tc6 *tc6)
> +{
> +	int ret;
> +
> +	while (true) {
> +		u16 spi_length = 0;
> +
> +		tc6->spi_data_tx_buf_offset = 0;
> +
> +		if (tc6->tx_skb || !skb_queue_empty(&tc6->tx_skb_q))
> +			spi_length = oa_tc6_prepare_spi_tx_buf_for_tx_skbs(tc6);
> +
> +		if (spi_length == 0)
> +			break;
> +
> +		ret = oa_tc6_spi_transfer(tc6, OA_TC6_DATA_HEADER, spi_length);
> +		if (ret) {
> +			netdev_err(tc6->netdev,
> +				   "SPI data transfer failed. Restart the system: %d\n",
> +				   ret);

What does Restart the system mean?

> +static int oa_tc6_spi_thread_handler(void *data)
> +{
> +	struct oa_tc6 *tc6 = data;
> +	int ret;
> +
> +	while (likely(!kthread_should_stop())) {
> +		/* This kthread will be waken up if there is a tx skb */
> +		wait_event_interruptible(tc6->spi_wq,
> +					 !skb_queue_empty(&tc6->tx_skb_q) ||
> +					 kthread_should_stop());
> +		ret = oa_tc6_try_spi_transfer(tc6);

Shouldn't you check why you have been woken up? It seems more logical
to test here for kthread_should_stop() rather than have
oa_tc6_try_spi_transfer() handle there is not actually a packet to be
sent.

	Andrew

  reply	other threads:[~2024-03-07 17:08 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06  8:50 [PATCH net-next v3 00/12] Add support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface Parthiban Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 01/12] Documentation: networking: add OPEN Alliance 10BASE-T1x MAC-PHY serial interface Parthiban Veerasooran
2024-03-06 13:23   ` Andrew Lunn
2024-03-07  6:29     ` Parthiban.Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 02/12] net: ethernet: oa_tc6: implement register write operation Parthiban Veerasooran
2024-03-06 13:40   ` Andrew Lunn
2024-03-07  6:46     ` Parthiban.Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 03/12] net: ethernet: oa_tc6: implement register read operation Parthiban Veerasooran
2024-03-07  0:19   ` Andrew Lunn
2024-03-07  7:04     ` Parthiban.Veerasooran
2024-03-07 13:22       ` Andrew Lunn
2024-03-08  7:12         ` Parthiban.Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 04/12] net: ethernet: oa_tc6: implement software reset Parthiban Veerasooran
2024-03-07  0:35   ` Andrew Lunn
2024-03-07  7:39     ` Parthiban.Veerasooran
2024-03-07 13:24       ` Andrew Lunn
2024-03-08  8:25         ` Parthiban.Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 05/12] net: ethernet: oa_tc6: implement error interrupts unmasking Parthiban Veerasooran
2024-03-07  0:43   ` Andrew Lunn
2024-03-07  8:28     ` Parthiban.Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 06/12] net: ethernet: oa_tc6: implement internal PHY initialization Parthiban Veerasooran
2024-03-07  1:13   ` Andrew Lunn
2024-03-07 14:41     ` Parthiban.Veerasooran
2024-03-07 16:36       ` Andrew Lunn
2024-03-08 12:05         ` Parthiban.Veerasooran
2024-03-08 13:33           ` Andrew Lunn
2024-03-18 11:01             ` Parthiban.Veerasooran
2024-04-12 10:43               ` Parthiban.Veerasooran
2024-04-15 13:15                 ` Andrew Lunn
2024-04-16 11:02                   ` Parthiban.Veerasooran
2024-04-16 18:18                     ` Andrew Lunn
2024-04-17  8:55                       ` Parthiban.Veerasooran
2024-03-21 18:49   ` Selvamani Rajagopal
2024-03-22  5:50     ` Parthiban.Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 07/12] net: ethernet: oa_tc6: enable open alliance tc6 data communication Parthiban Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 08/12] net: ethernet: oa_tc6: implement transmit path to transfer tx ethernet frames Parthiban Veerasooran
2024-03-07 17:08   ` Andrew Lunn [this message]
2024-03-19 12:54     ` Parthiban.Veerasooran
2024-03-19 13:19       ` Andrew Lunn
2024-03-20 10:43         ` Parthiban.Veerasooran
2024-03-21 19:04           ` Selvamani Rajagopal
2024-03-21 19:42             ` Andrew Lunn
2024-03-22 18:31               ` Selvamani Rajagopal
2024-03-06  8:50 ` [PATCH net-next v3 09/12] net: ethernet: oa_tc6: implement receive path to receive rx " Parthiban Veerasooran
2024-03-08  0:14   ` Andrew Lunn
2024-03-19 12:54     ` Parthiban.Veerasooran
2024-03-19 13:20       ` Andrew Lunn
2024-03-20  5:55         ` Parthiban.Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 10/12] net: ethernet: oa_tc6: implement mac-phy interrupt Parthiban Veerasooran
2024-03-06 23:42   ` Woojung.Huh
2024-03-07 10:16     ` Parthiban.Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 11/12] microchip: lan865x: add driver support for Microchip's LAN865X MAC-PHY Parthiban Veerasooran
2024-03-06 23:44   ` Woojung.Huh
2024-03-07  9:13     ` Parthiban.Veerasooran
2024-03-06  8:50 ` [PATCH net-next v3 12/12] dt-bindings: net: add Microchip's LAN865X 10BASE-T1S MACPHY Parthiban Veerasooran
2024-03-06 18:16   ` Conor Dooley
2024-03-06 18:48     ` Andrew Lunn
2024-03-06 19:01       ` Conor Dooley
2024-03-20  8:40         ` Parthiban.Veerasooran
2024-03-20  9:53           ` Krzysztof Kozlowski
2024-03-21  8:38             ` Parthiban.Veerasooran
2024-03-21  8:40               ` Krzysztof Kozlowski
2024-03-21 12:00                 ` Parthiban.Veerasooran
2024-03-21 15:34                   ` Conor Dooley
2024-03-22  6:25                     ` Parthiban.Veerasooran
2024-03-22  7:03                       ` Krzysztof Kozlowski
2024-03-22  8:28                         ` Parthiban.Veerasooran
2024-03-23 10:24                           ` Krzysztof Kozlowski
2024-03-25  7:10                             ` Parthiban.Veerasooran
2024-03-25  7:10                             ` Parthiban.Veerasooran
2024-03-22 18:08                       ` Conor Dooley
2024-03-25  7:12                         ` Parthiban.Veerasooran
2024-03-20  8:40     ` Parthiban.Veerasooran

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=208fb61b-4740-46bf-8c70-29ab59cbb965@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=Parthiban.Veerasooran@microchip.com \
    --cc=Pier.Beruto@onsemi.com \
    --cc=Selvamani.Rajagopal@onsemi.com \
    --cc=Thorsten.Kummermehr@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=benjamin.bigler@bernformulastudent.ch \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=horms@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=ruanjinjie@huawei.com \
    --cc=saeedm@nvidia.com \
    --cc=steen.hegelund@microchip.com \
    --cc=vladimir.oltean@nxp.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;
as well as URLs for NNTP newsgroup(s).