Thread (79 messages) 79 messages, 6 authors, 2024-07-08

Re: [PATCH net-next v13 06/15] net: stmmac: dwmac-loongson: Detach GMAC-specific platform data init

From: Serge Semin <hidden>
Date: 2024-07-07 10:40:36

On Sat, Jul 06, 2024 at 09:31:43PM +0800, Yanteng Si wrote:
quoted hunk ↗ jump to hunk
在 2024/7/5 19:53, Serge Semin 写道:
quoted
quoted
$: cat /proc/interrupts

            CPU0       CPU1
  20:       3826      12138   CPUINTC  12  IPI
  21:      15242      11791   CPUINTC  11  timer
  22:          0          0   PCH PIC   1  acpi
  28:          0          0   PCH PIC   7  loongson-alarm
  29:          0          0   PCH PIC   8  ls2x-i2c, ls2x-i2c, ls2x-i2c,
ls2x-i2c, ls2x-i2c, ls2x-i2c
  34:       7456          0   LIOINTC  10  ttyS0
  42:       1192          0   PCH PIC  17  0000:00:06.1
  43:          0          0   PCH PIC  18  ahci[0000:00:08.0]
  44:         40          0   PCH PIC  19  enp0s3f0
  45:          0          0   PCH PIC  20  enp0s3f1
  46:       1446          0   PCH PIC  21  enp0s3f2
  47:      11164          0   PCH PIC  22  xhci-hcd:usb1
  48:        338          0   PCH PIC  23  xhci-hcd:usb3
  49:          0          0   PCH PIC  24  snd_hda_intel:card0
IPI0:       117        132  LoongArch  1  Rescheduling interrupts
IPI1:      3713      12007  LoongArch  2  Function call interrupts
ERR:          1
So, what made you thinking that the enp0s3f0, enp0s3f1 and enp0s3f2
interfaces weren't working? I failed to find any immediate problem in
the log.
I'm sorry. I made a mistake. It works fine.
quoted
The driver registered eight Rx-queues (and likely eight Tx-queues).
enp0s3f0 and enp0s3f2 links got up. Even the log reported that two
interfaces have some network access (whatever it meant in your
boot-script):
quoted
The device(7a03 and 7a13) can access the network.
Yes, there is only one IRQ registered for each interface. But that's
what was expected seeing you have a single MAC IRQ detected. The
main question is: do the network traffic still get to flow in this
case? Are you able to send/receive data over all the DMA-channels?
Yes, I can. in this case, enp0s3f0/1/2 can access www.sing.com.


Because I did another test. I turn on the checksum.
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 25ddd99ae112..e1cde9e0e530 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -133,8 +133,8 @@ static int loongson_gmac_data(struct pci_dev *pdev,
                /* Only channel 0 supports checksum,
                 * so turn off checksum to enable multiple channels.
                 */
-               for (i = 1; i < CHANNEL_NUM; i++)
-                       plat->tx_queues_cfg[i].coe_unsupported = 1;
+               // for (i = 1; i < CHANNEL_NUM; i++)
+                       // plat->tx_queues_cfg[i].coe_unsupported = 1;
        } else {
                plat->tx_queues_to_use = 1;
                plat->rx_queues_to_use = 1;
@@ -185,8 +185,8 @@ static int loongson_gnet_data(struct pci_dev *pdev,
                /* Only channel 0 supports checksum,
                 * so turn off checksum to enable multiple channels.
                 */
-               for (i = 1; i < CHANNEL_NUM; i++)
-                       plat->tx_queues_cfg[i].coe_unsupported = 1;
+               // for (i = 1; i < CHANNEL_NUM; i++)
+                       // plat->tx_queues_cfg[i].coe_unsupported = 1;
        } else {
                plat->tx_queues_to_use = 1;
                plat->rx_queues_to_use = 1;
@@ -576,11 +576,11 @@ static int loongson_dwmac_probe(struct pci_dev *pdev,> const struct pci_device_id
        if (ret)
                goto err_disable_device;

-       if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
-               ret = loongson_dwmac_msi_config(pdev, plat, &res);
-               if (ret)
-                       goto err_disable_device;
-       }
+       if (ld->loongson_id == DWMAC_CORE_LOONGSON_MULTI_CH) {
+               // ret = loongson_dwmac_msi_config(pdev, plat, &res);
+               // if (ret)
+                       // goto err_disable_device;
+       // }

        ret = stmmac_dvr_probe(&pdev->dev, plat, &res);
        if (ret)

In this case, enp0s3f0/1/2 cannot access the www.sing.com.
Smart.) Indeed it implicitly proves that at least two channels get to
work. Checking out the interface queues statistics (ethtool -S
<interface>) would make it less implicit. Although something more
comprehensive covering all the channels would be better. But it's up
to you to decide whether you need such test implemented and performed.
I just wanted to make sure whether the common MAC IRQ case was indeed
tested since your original result contradicted to what the DW MAC
explicitly stated:

"The interrupts from different DMA channels are combined by using the
OR function to generate a single interrupt signal sbd_intr_o.
Therefore, the software needs to read the Interrupt Status Registers
of all DMA channels to get the source of interrupt. The MAC interrupt
status (Bits [29:26]) is updated only in the interrupt status register
of Channel 0."

The sbd_intr_o line is the main IRQ signal reporting all the DMA and
MAC events (so called "macirq" in the STMMAC driver). (There is a case
when the later events are reported via a separate mci_intr_o wire, but
it's rather rare.) So it seemed strange that the Loongson GMAC/GNET
HW-designers could have diverted the IRQs delivery logic so much.
That's why I was so persistent in asking the way the test was
performed.

-Serge(y)
therefore, the network traffic still get to flow, and I can

send/receive data over all the DMA-channels.

If there are any other tests you would like me to do, please let

me know and I will be happy to do them.

Thanks,

Yanteng
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help