All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Parthiban.Veerasooran@microchip.com>
To: <andrew@lunn.ch>
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: Tue, 19 Mar 2024 12:54:30 +0000	[thread overview]
Message-ID: <f9d8a18c-b1fe-450c-a5ca-d91f96793a04@microchip.com> (raw)
In-Reply-To: <208fb61b-4740-46bf-8c70-29ab59cbb965@lunn.ch>

Hi Andrew,

On 07/03/24 10:38 pm, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> @@ -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.
Thanks for the detailed explanation. If I understand you correctly,

1. The tx skb queue size (OA_TC6_TX_SKB_QUEUE_SIZE) should be 2 to avoid 
the latency when a high priority packet added.

2. Need to implement the handling part of the below case,
In case if one packet ends in a chunk and that chunk still having some 
space left to accommodate some bytes from the next packet if available 
from network layer.

Will implement in the next version.
> 
>> +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.
Ah ok. Then probably I have to add the below code in the 
oa_tc6_start_xmit() function before adding the skb into the transmit queue.

if (skb_linearize(skb)) {
	dev_kfree_skb_any(skb);
	tc6->netdev->stats.tx_dropped++;
	return NETDEV_TX_OK;
}

> 
>> +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?
Hmm, actually if SPI transfer failed then it can be hardware failure or 
poor SPI connection. Now I realize that just restarting the system will 
not help. I will remove "Restart the system:" as it is not the correct info.
> 
>> +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.
Ok, then I will add the below code before the oa_tc6_try_spi_transfer().

if (kthread_should_stop())
	break;

Best regards,
Parthiban V
> 
>          Andrew
> 


  reply	other threads:[~2024-03-19 12:55 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
2024-03-19 12:54     ` Parthiban.Veerasooran [this message]
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=f9d8a18c-b1fe-450c-a5ca-d91f96793a04@microchip.com \
    --to=parthiban.veerasooran@microchip.com \
    --cc=Horatiu.Vultur@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=Pier.Beruto@onsemi.com \
    --cc=Selvamani.Rajagopal@onsemi.com \
    --cc=Steen.Hegelund@microchip.com \
    --cc=Thorsten.Kummermehr@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --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=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=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 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.