The D_CAN controller supports up to 128 messages. Until now the driver
only managed 32 messages although Sitara processors and DRA7 SOC can
handle 64.
The series was tested on a beaglebone board.
Note:
I have not changed the type of tx_field (belonging to the c_can_priv
structure) to atomic64_t because I think the atomic_t type has size
of at least 32 bits on x86 and arm, which is enough to handle 64
messages.
http://marc.info/?l=linux-can&m=139746476821294&w=2 reports the results
of tests performed just on x86 and arm architectures.
Changes in v3:
- Use unsigned int instead of int as type of the msg_obj_* fields
in the c_can_priv structure.
- Replace (u64)1 with 1UL in msg_obj_rx_mask setting.
- Use unsigned int instead of int as type of the msg_obj_num field
in c_can_driver_data and c_can_pci_data structures.
Changes in v2:
- Fix compiling error reported by kernel test robot.
- Add Reported-by tag.
- Pass larger size to alloc_candev() routine to avoid an additional
memory allocation/deallocation.
- Add message objects number to PCI driver data.
Dario Binacchi (6):
can: c_can: remove unused code
can: c_can: fix indentation
can: c_can: fix control interface used by c_can_do_tx
can: c_can: use 32-bit write to set arbitration register
can: c_can: prepare to up the message objects number
can: c_can: add support to 64 message objects
drivers/net/can/c_can/c_can.c | 77 +++++++++++++++-----------
drivers/net/can/c_can/c_can.h | 32 +++++------
drivers/net/can/c_can/c_can_pci.c | 6 +-
drivers/net/can/c_can/c_can_platform.c | 6 +-
4 files changed, 68 insertions(+), 53 deletions(-)
--
2.17.1
As pointed by commit c0a9f4d396c9 ("can: c_can: Reduce register access")
the "driver casts the 16 message objects in stone, which is completely
braindead as contemporary hardware has up to 128 message objects".
The patch prepares the module to extend the number of message objects
beyond the 32 currently managed. This was achieved by transforming the
constants used to manage RX/TX messages into variables without changing
the driver policy.
Signed-off-by: Dario Binacchi <redacted>
Reported-by: kernel test robot <redacted>
---
Changes in v3:
- Use unsigned int instead of int as type of the msg_obj_* fields
in the c_can_priv structure.
- Replace (u64)1 with 1UL in msg_obj_rx_mask setting.
Changes in v2:
- Fix compiling error reported by kernel test robot.
- Add Reported-by tag.
- Pass larger size to alloc_candev() routine to avoid an additional
memory allocation/deallocation.
drivers/net/can/c_can/c_can.c | 50 ++++++++++++++++----------
drivers/net/can/c_can/c_can.h | 23 ++++++------
drivers/net/can/c_can/c_can_pci.c | 2 +-
drivers/net/can/c_can/c_can_platform.c | 2 +-
4 files changed, 43 insertions(+), 34 deletions(-)
@@ -173,9 +173,6 @@/* Wait for ~1 sec for INIT bit */#define INIT_WAIT_MS 1000-/* napi related */-#define C_CAN_NAPI_WEIGHT C_CAN_MSG_OBJ_RX_NUM-/* c_can lec values */enumc_can_lec_type{LEC_NO_ERROR=0,
@@ -463,10 +460,10 @@ static netdev_tx_t c_can_start_xmit(struct sk_buff *skb,*prioritized.Thelowestbuffernumberwins.*/idx=fls(atomic_read(&priv->tx_active));-obj=idx+C_CAN_MSG_OBJ_TX_FIRST;+obj=idx+priv->msg_obj_tx_first;/* If this is the last buffer, stop the xmit queue */-if(idx==C_CAN_MSG_OBJ_TX_NUM-1)+if(idx==priv->msg_obj_tx_num-1)netif_stop_queue(dev);/**Storethemessageintheinterfacesowecancall
@@ -549,17 +546,18 @@ static int c_can_set_bittiming(struct net_device *dev)*/staticvoidc_can_configure_msg_objects(structnet_device*dev){+structc_can_priv*priv=netdev_priv(dev);inti;/* first invalidate all message objects */-for(i=C_CAN_MSG_OBJ_RX_FIRST;i<=C_CAN_NO_OF_OBJECTS;i++)+for(i=priv->msg_obj_rx_first;i<=priv->msg_obj_num;i++)c_can_inval_msg_object(dev,IF_RX,i);/* setup receive message objects */-for(i=C_CAN_MSG_OBJ_RX_FIRST;i<C_CAN_MSG_OBJ_RX_LAST;i++)+for(i=priv->msg_obj_rx_first;i<priv->msg_obj_rx_last;i++)c_can_setup_receive_object(dev,IF_RX,i,0,0,IF_MCONT_RCV);-c_can_setup_receive_object(dev,IF_RX,C_CAN_MSG_OBJ_RX_LAST,0,0,+c_can_setup_receive_object(dev,IF_RX,priv->msg_obj_rx_last,0,0,IF_MCONT_RCV_EOB);}
@@ -862,8 +860,7 @@ static int c_can_do_rx_poll(struct net_device *dev, int quota)*Itisfastertoreadonlyone16bitregister.Thisisonlypossible*foramaximumnumberof16objects.*/-BUILD_BUG_ON_MSG(C_CAN_MSG_OBJ_RX_LAST>16,-"Implementation does not support more message objects than 16");+WARN_ON(priv->msg_obj_rx_last>16);while(quota>0){if(!pend){
@@ -874,7 +871,8 @@ static int c_can_do_rx_poll(struct net_device *dev, int quota)*Ifthependingfieldhasagap,handlethe*bitsabovethegapfirst.*/-toread=c_can_adjust_pending(pend);+toread=c_can_adjust_pending(pend,+priv->msg_obj_rx_mask);}else{toread=pend;}
@@ -1205,17 +1203,31 @@ static int c_can_close(struct net_device *dev)return0;}-structnet_device*alloc_c_can_dev(void)+structnet_device*alloc_c_can_dev(intmsg_obj_num){structnet_device*dev;structc_can_priv*priv;+intmsg_obj_tx_num=msg_obj_num/2;-dev=alloc_candev(sizeof(structc_can_priv),C_CAN_MSG_OBJ_TX_NUM);+dev=alloc_candev(sizeof(*priv)+sizeof(u32)*msg_obj_tx_num,+msg_obj_tx_num);if(!dev)returnNULL;priv=netdev_priv(dev);-netif_napi_add(dev,&priv->napi,c_can_poll,C_CAN_NAPI_WEIGHT);+priv->msg_obj_num=msg_obj_num;+priv->msg_obj_rx_num=msg_obj_num-msg_obj_tx_num;+priv->msg_obj_rx_first=1;+priv->msg_obj_rx_last=+priv->msg_obj_rx_first+priv->msg_obj_rx_num-1;+priv->msg_obj_rx_mask=(1UL<<priv->msg_obj_rx_num)-1;++priv->msg_obj_tx_num=msg_obj_tx_num;+priv->msg_obj_tx_first=priv->msg_obj_rx_last+1;+priv->msg_obj_tx_last=+priv->msg_obj_tx_first+priv->msg_obj_tx_num-1;++netif_napi_add(dev,&priv->napi,c_can_poll,priv->msg_obj_rx_num);priv->dev=dev;priv->can.bittiming_const=&c_can_bittiming_const;
The arbitration register is already set up with 32-bit writes in the
other parts of the code except for this point.
Signed-off-by: Dario Binacchi <redacted>
---
(no changes since v1)
drivers/net/can/c_can/c_can.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
According to commit 640916db2bf7 ("can: c_can: Make it SMP safe") let RX use
IF1 (i.e. IF_RX) and TX use IF2 (i.e. IF_TX).
Signed-off-by: Dario Binacchi <redacted>
---
(no changes since v1)
drivers/net/can/c_can/c_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
D_CAN controller supports 16, 32, 64 or 128 message objects, comparing
to 32 on C_CAN.
AM335x/AM437x Sitara processors and DRA7 SOC all instantiate a D_CAN
controller with 64 message objects, as described in the "DCAN features"
subsection of the CAN chapter of their technical reference manuals.
The driver policy has been kept unchanged, and as in the previous
version, the first half of the message objects is used for reception and
the second for transmission.
The I/O load is increased only in the case of 64 message objects,
keeping it unchanged in the case of 32. Two 32-bit read accesses are in
fact required, which however remained at 16-bit for configurations with
32 message objects.
Signed-off-by: Dario Binacchi <redacted>
---
Changes in v3:
- Use unsigned int instead of int as type of the msg_obj_num field
in c_can_driver_data and c_can_pci_data structures.
Changes in v2:
- Add message objects number to PCI driver data.
drivers/net/can/c_can/c_can.c | 19 +++++++++++--------
drivers/net/can/c_can/c_can.h | 5 +++--
drivers/net/can/c_can/c_can_pci.c | 6 +++++-
drivers/net/can/c_can/c_can_platform.c | 6 +++++-
4 files changed, 24 insertions(+), 12 deletions(-)
@@ -31,6 +31,8 @@ enum c_can_pci_reg_align {structc_can_pci_data{/* Specify if is C_CAN or D_CAN */enumc_can_dev_idtype;+/* Number of message objects */+unsignedintmsg_obj_num;/* Set the register alignment in the memory */enumc_can_pci_reg_alignreg_align;/* Set the frequency */
@@ -149,7 +151,7 @@ static int c_can_pci_probe(struct pci_dev *pdev,}/* allocate the c_can device */-dev=alloc_c_can_dev(C_CAN_NO_OF_OBJECTS);+dev=alloc_c_can_dev(c_can_pci_data->msg_obj_num);if(!dev){ret=-ENOMEM;gotoout_iounmap;
@@ -740,7 +738,7 @@ static void c_can_do_tx(struct net_device *dev) /* Clear the bits in the tx_active mask */ atomic_sub(clr, &priv->tx_active);- if (clr & (1 << (C_CAN_MSG_OBJ_TX_NUM - 1)))+ if (clr & (1 << (priv->msg_obj_tx_num - 1)))
Do we need 1UL here, too?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
@@ -740,7 +738,7 @@ static void c_can_do_tx(struct net_device *dev) /* Clear the bits in the tx_active mask */ atomic_sub(clr, &priv->tx_active);- if (clr & (1 << (C_CAN_MSG_OBJ_TX_NUM - 1)))+ if (clr & (1 << (priv->msg_obj_tx_num - 1)))
Do we need 1UL here, too?
There are several more "1 <<" in the driver. As the right side of the
sift operation can be up to 32, I think you should replace all "1 <<"
with "1UL <<".
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
@@ -740,7 +738,7 @@ static void c_can_do_tx(struct net_device *dev) /* Clear the bits in the tx_active mask */ atomic_sub(clr, &priv->tx_active);- if (clr & (1 << (C_CAN_MSG_OBJ_TX_NUM - 1)))+ if (clr & (1 << (priv->msg_obj_tx_num - 1)))
Do we need 1UL here, too?
There are several more "1 <<" in the driver. As the right side of the
sift operation can be up to 32, I think you should replace all "1 <<"
with "1UL <<".
Do you agree if I use the BIT macro for all these shift operations?
Thanks and regards
Dario
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
@@ -740,7 +738,7 @@ static void c_can_do_tx(struct net_device *dev) /* Clear the bits in the tx_active mask */ atomic_sub(clr, &priv->tx_active);- if (clr & (1 << (C_CAN_MSG_OBJ_TX_NUM - 1)))+ if (clr & (1 << (priv->msg_obj_tx_num - 1)))
Do we need 1UL here, too?
There are several more "1 <<" in the driver. As the right side of the
sift operation can be up to 32, I think you should replace all "1 <<"
with "1UL <<".
Do you agree if I use the BIT macro for all these shift operations?
No, only use BIT(), where you want to set a single bit, use GENMASK()
for masks.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
@@ -740,7 +738,7 @@ static void c_can_do_tx(struct net_device *dev) /* Clear the bits in the tx_active mask */ atomic_sub(clr, &priv->tx_active);- if (clr & (1 << (C_CAN_MSG_OBJ_TX_NUM - 1)))+ if (clr & (1 << (priv->msg_obj_tx_num - 1)))
Do we need 1UL here, too?
There are several more "1 <<" in the driver. As the right side of the
sift operation can be up to 32, I think you should replace all "1 <<"
with "1UL <<".
Even better use BIT() for setting single bits and GENMASK() to generate
masks.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
@@ -740,7 +738,7 @@ static void c_can_do_tx(struct net_device *dev) /* Clear the bits in the tx_active mask */ atomic_sub(clr, &priv->tx_active);- if (clr & (1 << (C_CAN_MSG_OBJ_TX_NUM - 1)))+ if (clr & (1 << (priv->msg_obj_tx_num - 1)))
Do we need 1UL here, too?
Do you agree if I use the BIT macro ?
No, please use GENMASK(priv->msg_obj_tx_num, 0) here.
In case of 64 message objects, msg_obj_tx_num = 32, and 1 << (priv->msg_obj_tx_num - 1) = 0x80000000.
GENMASK(priv->msg_obj_tx_num, 0) = 0.
BIT(priv->msg_obj_tx_num - 1) = 0x80000000.
Doh! I've misread where the -1 is places.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
From: Kurt Van Dijck <hidden> Date: 2021-03-02 22:10:52
On Sun, 28 Feb 2021 11:38:52 +0100, Dario Binacchi wrote:
quoted hunk
According to commit 640916db2bf7 ("can: c_can: Make it SMP safe") let RX use
IF1 (i.e. IF_RX) and TX use IF2 (i.e. IF_TX).
Signed-off-by: Dario Binacchi <redacted>
---
(no changes since v1)
drivers/net/can/c_can/c_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Right. I had a similar effort last year to increase the reception
throughput, but I ended with some sporadic strange tx echo problems.
This fix may have fixed my problem as wel.
From: Kurt Van Dijck <hidden> Date: 2021-03-02 22:11:05
On Sun, 28 Feb 2021 11:38:54 +0100, Dario Binacchi wrote:
quoted hunk
Date: Sun, 28 Feb 2021 11:38:54 +0100
From: Dario Binacchi <redacted>
To: linux-kernel@vger.kernel.org
Cc: Federico Vaga <redacted>, Alexander Stein
[off-list ref], Dario Binacchi
[off-list ref], "David S. Miller" [off-list ref], Jakub
Kicinski [off-list ref], Marc Kleine-Budde [off-list ref], Oliver
Hartkopp [off-list ref], Vincent Mailhol
[off-list ref], Wolfgang Grandegger [off-list ref],
YueHaibing [off-list ref], Zhang Qilong
[off-list ref], linux-can@vger.kernel.org,
netdev@vger.kernel.org
Subject: [PATCH v3 5/6] can: c_can: prepare to up the message objects number
X-Mailer: git-send-email 2.17.1
As pointed by commit c0a9f4d396c9 ("can: c_can: Reduce register access")
the "driver casts the 16 message objects in stone, which is completely
braindead as contemporary hardware has up to 128 message objects".
The patch prepares the module to extend the number of message objects
beyond the 32 currently managed. This was achieved by transforming the
constants used to manage RX/TX messages into variables without changing
the driver policy.
Signed-off-by: Dario Binacchi <redacted>
Reported-by: kernel test robot <redacted>
---
Changes in v3:
- Use unsigned int instead of int as type of the msg_obj_* fields
in the c_can_priv structure.
- Replace (u64)1 with 1UL in msg_obj_rx_mask setting.
Changes in v2:
- Fix compiling error reported by kernel test robot.
- Add Reported-by tag.
- Pass larger size to alloc_candev() routine to avoid an additional
memory allocation/deallocation.
drivers/net/can/c_can/c_can.c | 50 ++++++++++++++++----------
drivers/net/can/c_can/c_can.h | 23 ++++++------
drivers/net/can/c_can/c_can_pci.c | 2 +-
drivers/net/can/c_can/c_can_platform.c | 2 +-
4 files changed, 43 insertions(+), 34 deletions(-)
@@ -173,9 +173,6 @@/* Wait for ~1 sec for INIT bit */#define INIT_WAIT_MS 1000-/* napi related */-#define C_CAN_NAPI_WEIGHT C_CAN_MSG_OBJ_RX_NUM-/* c_can lec values */enumc_can_lec_type{LEC_NO_ERROR=0,
@@ -463,10 +460,10 @@ static netdev_tx_t c_can_start_xmit(struct sk_buff *skb,*prioritized.Thelowestbuffernumberwins.*/idx=fls(atomic_read(&priv->tx_active));-obj=idx+C_CAN_MSG_OBJ_TX_FIRST;+obj=idx+priv->msg_obj_tx_first;/* If this is the last buffer, stop the xmit queue */-if(idx==C_CAN_MSG_OBJ_TX_NUM-1)+if(idx==priv->msg_obj_tx_num-1)netif_stop_queue(dev);/**Storethemessageintheinterfacesowecancall
@@ -549,17 +546,18 @@ static int c_can_set_bittiming(struct net_device *dev)*/staticvoidc_can_configure_msg_objects(structnet_device*dev){+structc_can_priv*priv=netdev_priv(dev);inti;/* first invalidate all message objects */-for(i=C_CAN_MSG_OBJ_RX_FIRST;i<=C_CAN_NO_OF_OBJECTS;i++)+for(i=priv->msg_obj_rx_first;i<=priv->msg_obj_num;i++)c_can_inval_msg_object(dev,IF_RX,i);/* setup receive message objects */-for(i=C_CAN_MSG_OBJ_RX_FIRST;i<C_CAN_MSG_OBJ_RX_LAST;i++)+for(i=priv->msg_obj_rx_first;i<priv->msg_obj_rx_last;i++)c_can_setup_receive_object(dev,IF_RX,i,0,0,IF_MCONT_RCV);-c_can_setup_receive_object(dev,IF_RX,C_CAN_MSG_OBJ_RX_LAST,0,0,+c_can_setup_receive_object(dev,IF_RX,priv->msg_obj_rx_last,0,0,IF_MCONT_RCV_EOB);}
@@ -862,8 +860,7 @@ static int c_can_do_rx_poll(struct net_device *dev, int quota)*Itisfastertoreadonlyone16bitregister.Thisisonlypossible*foramaximumnumberof16objects.*/-BUILD_BUG_ON_MSG(C_CAN_MSG_OBJ_RX_LAST>16,-"Implementation does not support more message objects than 16");+WARN_ON(priv->msg_obj_rx_last>16);while(quota>0){if(!pend){
@@ -874,7 +871,8 @@ static int c_can_do_rx_poll(struct net_device *dev, int quota)*Ifthependingfieldhasagap,handlethe*bitsabovethegapfirst.*/-toread=c_can_adjust_pending(pend);+toread=c_can_adjust_pending(pend,+priv->msg_obj_rx_mask);}else{toread=pend;}
@@ -1205,17 +1203,31 @@ static int c_can_close(struct net_device *dev)return0;}-structnet_device*alloc_c_can_dev(void)+structnet_device*alloc_c_can_dev(intmsg_obj_num){structnet_device*dev;structc_can_priv*priv;+intmsg_obj_tx_num=msg_obj_num/2;
IMO, a bigger tx queue is not usefull.
A bigger rx queue however is.
My series last year took a fixed lenght of 8 for tx,
and use the remaining as rx queue.
Il 02/03/2021 19:44 Kurt Van Dijck [off-list ref] ha scritto:
On Sun, 28 Feb 2021 11:38:52 +0100, Dario Binacchi wrote:
quoted
According to commit 640916db2bf7 ("can: c_can: Make it SMP safe") let RX use
IF1 (i.e. IF_RX) and TX use IF2 (i.e. IF_TX).
Signed-off-by: Dario Binacchi <redacted>
---
(no changes since v1)
drivers/net/can/c_can/c_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Right. I had a similar effort last year to increase the reception
throughput, but I ended with some sporadic strange tx echo problems.
This fix may have fixed my problem as well.
IMO, a bigger tx queue is not usefull.
A bigger rx queue however is.
This would not be good for my application. I think it really depends
on the type of application. We can probably say that being able to
size rx/tx queue would be a useful feature.
Ok. There is an ethtool interface to configure the size of the RX and TX
queues. In ethtool it's called the RX/TX "ring" size and you can get it
via the -g parameter, e.g. here for by Ethernet interface:
| $ ethtool -g enp0s25
| Ring parameters for enp0s25:
| Pre-set maximums:
| RX: 4096
| RX Mini: n/a
| RX Jumbo: n/a
| TX: 4096
| Current hardware settings:
| RX: 256
| RX Mini: n/a
| RX Jumbo: n/a
| TX: 256
If I understand correctly patch 6 has some assumptions that RX and TX
are max 32. To support up to 64 RX objects, you have to convert:
- u32 -> u64
- BIT() -> BIT_ULL()
- GENMASK() -> GENMASK_ULL()
The register access has to be converted, too. For performance reasons
you want to do as least as possible. Which is probably the most
complicated.
In the flexcan driver I have a similar problem. The driver keeps masks,
which mailboxes are RX and which TX and I added wrapper functions to
minimize IO access:
https://elixir.bootlin.com/linux/v5.11/source/drivers/net/can/flexcan.c#L904
This should to IMHO into patch 6.
Adding the ethtool support and making the rings configurable would be a
separate patch.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Il 02/03/2021 19:49 Kurt Van Dijck [off-list ref] ha scritto:
On Sun, 28 Feb 2021 11:38:54 +0100, Dario Binacchi wrote:
quoted
Date: Sun, 28 Feb 2021 11:38:54 +0100
From: Dario Binacchi <redacted>
To: linux-kernel@vger.kernel.org
Cc: Federico Vaga <redacted>, Alexander Stein
[off-list ref], Dario Binacchi
[off-list ref], "David S. Miller" [off-list ref], Jakub
Kicinski [off-list ref], Marc Kleine-Budde [off-list ref], Oliver
Hartkopp [off-list ref], Vincent Mailhol
[off-list ref], Wolfgang Grandegger [off-list ref],
YueHaibing [off-list ref], Zhang Qilong
[off-list ref], linux-can@vger.kernel.org,
netdev@vger.kernel.org
Subject: [PATCH v3 5/6] can: c_can: prepare to up the message objects number
X-Mailer: git-send-email 2.17.1
As pointed by commit c0a9f4d396c9 ("can: c_can: Reduce register access")
the "driver casts the 16 message objects in stone, which is completely
braindead as contemporary hardware has up to 128 message objects".
The patch prepares the module to extend the number of message objects
beyond the 32 currently managed. This was achieved by transforming the
constants used to manage RX/TX messages into variables without changing
the driver policy.
Signed-off-by: Dario Binacchi <redacted>
Reported-by: kernel test robot <redacted>
---
Changes in v3:
- Use unsigned int instead of int as type of the msg_obj_* fields
in the c_can_priv structure.
- Replace (u64)1 with 1UL in msg_obj_rx_mask setting.
Changes in v2:
- Fix compiling error reported by kernel test robot.
- Add Reported-by tag.
- Pass larger size to alloc_candev() routine to avoid an additional
memory allocation/deallocation.
drivers/net/can/c_can/c_can.c | 50 ++++++++++++++++----------
drivers/net/can/c_can/c_can.h | 23 ++++++------
drivers/net/can/c_can/c_can_pci.c | 2 +-
drivers/net/can/c_can/c_can_platform.c | 2 +-
4 files changed, 43 insertions(+), 34 deletions(-)
@@ -173,9 +173,6 @@/* Wait for ~1 sec for INIT bit */#define INIT_WAIT_MS 1000-/* napi related */-#define C_CAN_NAPI_WEIGHT C_CAN_MSG_OBJ_RX_NUM-/* c_can lec values */enumc_can_lec_type{LEC_NO_ERROR=0,
@@ -463,10 +460,10 @@ static netdev_tx_t c_can_start_xmit(struct sk_buff *skb,*prioritized.Thelowestbuffernumberwins.*/idx=fls(atomic_read(&priv->tx_active));-obj=idx+C_CAN_MSG_OBJ_TX_FIRST;+obj=idx+priv->msg_obj_tx_first;/* If this is the last buffer, stop the xmit queue */-if(idx==C_CAN_MSG_OBJ_TX_NUM-1)+if(idx==priv->msg_obj_tx_num-1)netif_stop_queue(dev);/**Storethemessageintheinterfacesowecancall
@@ -549,17 +546,18 @@ static int c_can_set_bittiming(struct net_device *dev)*/staticvoidc_can_configure_msg_objects(structnet_device*dev){+structc_can_priv*priv=netdev_priv(dev);inti;/* first invalidate all message objects */-for(i=C_CAN_MSG_OBJ_RX_FIRST;i<=C_CAN_NO_OF_OBJECTS;i++)+for(i=priv->msg_obj_rx_first;i<=priv->msg_obj_num;i++)c_can_inval_msg_object(dev,IF_RX,i);/* setup receive message objects */-for(i=C_CAN_MSG_OBJ_RX_FIRST;i<C_CAN_MSG_OBJ_RX_LAST;i++)+for(i=priv->msg_obj_rx_first;i<priv->msg_obj_rx_last;i++)c_can_setup_receive_object(dev,IF_RX,i,0,0,IF_MCONT_RCV);-c_can_setup_receive_object(dev,IF_RX,C_CAN_MSG_OBJ_RX_LAST,0,0,+c_can_setup_receive_object(dev,IF_RX,priv->msg_obj_rx_last,0,0,IF_MCONT_RCV_EOB);}
@@ -862,8 +860,7 @@ static int c_can_do_rx_poll(struct net_device *dev, int quota)*Itisfastertoreadonlyone16bitregister.Thisisonlypossible*foramaximumnumberof16objects.*/-BUILD_BUG_ON_MSG(C_CAN_MSG_OBJ_RX_LAST>16,-"Implementation does not support more message objects than 16");+WARN_ON(priv->msg_obj_rx_last>16);while(quota>0){if(!pend){
@@ -874,7 +871,8 @@ static int c_can_do_rx_poll(struct net_device *dev, int quota)*Ifthependingfieldhasagap,handlethe*bitsabovethegapfirst.*/-toread=c_can_adjust_pending(pend);+toread=c_can_adjust_pending(pend,+priv->msg_obj_rx_mask);}else{toread=pend;}
@@ -1205,17 +1203,31 @@ static int c_can_close(struct net_device *dev)return0;}-structnet_device*alloc_c_can_dev(void)+structnet_device*alloc_c_can_dev(intmsg_obj_num){structnet_device*dev;structc_can_priv*priv;+intmsg_obj_tx_num=msg_obj_num/2;
IMO, a bigger tx queue is not usefull.
A bigger rx queue however is.
This would not be good for my application.
I think it really depends on the type of application.
We can probably say that being able to size rx/tx queue
would be a useful feature.
Thanks and regards,
Dario
My series last year took a fixed lenght of 8 for tx,
and use the remaining as rx queue.
IMO, a bigger tx queue is not usefull.
A bigger rx queue however is.
This would not be good for my application. I think it really depends
on the type of application. We can probably say that being able to
size rx/tx queue would be a useful feature.
Ok. There is an ethtool interface to configure the size of the RX and TX
queues. In ethtool it's called the RX/TX "ring" size and you can get it
via the -g parameter, e.g. here for by Ethernet interface:
| $ ethtool -g enp0s25
| Ring parameters for enp0s25:
| Pre-set maximums:
| RX: 4096
| RX Mini: n/a
| RX Jumbo: n/a
| TX: 4096
| Current hardware settings:
| RX: 256
| RX Mini: n/a
| RX Jumbo: n/a
| TX: 256
If I understand correctly patch 6 has some assumptions that RX and TX
are max 32. To support up to 64 RX objects, you have to convert:
- u32 -> u64
- BIT() -> BIT_ULL()
- GENMASK() -> GENMASK_ULL()
The register access has to be converted, too. For performance reasons
you want to do as least as possible. Which is probably the most
complicated.
In the flexcan driver I have a similar problem. The driver keeps masks,
which mailboxes are RX and which TX and I added wrapper functions to
minimize IO access:
https://elixir.bootlin.com/linux/v5.11/source/drivers/net/can/flexcan.c#L904
This should to IMHO into patch 6.
Adding the ethtool support and making the rings configurable would be a
separate patch.
I think these features need to be developed in a later series.
I would stay with the extension to 64 messages equally divided
between reception and transmission.
Thanks and regards,
Dario
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-03-03 15:28:39
On 03.03.2021 11:31:10, Dario Binacchi wrote:
I think these features need to be developed in a later series.
I would stay with the extension to 64 messages equally divided
between reception and transmission.
Fine with me.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |