Re: [CFT] dmfe.c network driver update for 2.4
Hello,
I'll double check the locking later today, but not sure about the
transmission changes.
Regards,
Frank
([EMAIL PROTECTED])
--On Wednesday, November 15, 2000 9:34 PM +0100 Tobias Ringstrom
<[EMAIL PROTECTED]> wrote:
> I have updated the dmfe.c network driver for 2.4.0-test by adding proper
> locking (I hope), and also made transmission much efficient.
>
> I would appreciate any feedback from people using this driver, to confirm
> that I did not break it.
>
> It would also be great if someone could take a look at the lock handling,
> to confirm that is is correct and sufficient.
>
> /Tobias
>
>
> --- dmfe.c.orig Wed Nov 15 19:53:48 2000
> +++ dmfe.cWed Nov 15 21:35:24 2000
> @@ -57,6 +57,11 @@
> Resource usage cleanups.
> Report driver version to user.
>
> + Tobias Ringström <[EMAIL PROTECTED]> :
> + Added proper locking.
> + Rewrote the transmit code to actually use the ring buffer,
> + and to generate a lot fewer interrupts.
> +
> TODO
>
> Implement pci_driver::suspend() and pci_driver::resume()
> @@ -108,6 +113,7 @@
> #define TX_MAX_SEND_CNT 0x1 /* Maximum tx packet per time */
> #define TX_DESC_CNT 0x10 /* Allocated Tx descriptors */
> #define RX_DESC_CNT 0x10 /* Allocated Rx descriptors */
> +#define TX_IRQ_THR 12
> #define DESC_ALL_CNTTX_DESC_CNT+RX_DESC_CNT
> #define TX_BUF_ALLOC0x600
> #define RX_ALLOC_SIZE 0x620
> @@ -188,6 +194,8 @@
>u32 cr7_data;
>u32 cr15_data;
>
> + spinlock_t lock;
> +
>/* descriptor pointer */
>unsigned char *buf_pool_ptr; /* Tx buffer pool memory */
>unsigned char *buf_pool_start; /* Tx buffer pool align dword */
> @@ -198,8 +206,7 @@
>struct rx_desc *first_rx_desc;
>struct rx_desc *rx_insert_ptr;
>struct rx_desc *rx_ready_ptr; /* packet come pointer */
> - u32 tx_packet_cnt; /* transmitted packet count */
> - u32 tx_queue_cnt; /* wait to send packet count */
> + u32 tx_live_cnt;/* number of used/live tx slots */
>u32 rx_avail_cnt; /* available rx descriptor count */
>u32 interval_rx_cnt; /* rx packet count a callback time */
>
> @@ -490,8 +497,6 @@
>
>/* system variable init */
>db->cr6_data = CR6_DEFAULT | dmfe_cr6_user_set;
> - db->tx_packet_cnt = 0;
> - db->tx_queue_cnt = 0;
>db->rx_avail_cnt = 0;
>db->link_failed = 0;
>db->wait_reset = 0;
> @@ -595,46 +600,42 @@
> {
>struct dmfe_board_info *db = dev->priv;
>struct tx_desc *txptr;
> + static unsigned pkt_num = TX_IRQ_THR;
>
>DMFE_DBUG(0, "dmfe_start_xmit", 0);
> -
> - netif_stop_queue(dev);
> -
> - /* Too large packet check */
> - if (skb->len > MAX_PACKET_SIZE) {
> - printk(KERN_ERR "%s: oversized frame (%d bytes) for transmit.\n",
> dev->name, (u16) skb->len); - dev_kfree_skb(skb);
> - return 0;
> - }
> - /* No Tx resource check, it never happen nromally */
> - if (db->tx_packet_cnt >= TX_FREE_DESC_CNT) {
> - return 1;
> - }
> +
> + spin_lock_irq(&db->lock);
>
>/* transmit this packet */
>txptr = db->tx_insert_ptr;
>memcpy((char *) txptr->tx_buf_ptr, (char *) skb->data, skb->len);
> - txptr->tdes1 = 0xe100 | skb->len;
> + if (--pkt_num == 0)
> + {
> + txptr->tdes1 = 0xe100 | skb->len;
> + pkt_num = TX_IRQ_THR;
> + }
> + else
> + txptr->tdes1 = 0x6100 | skb->len;
> +
> + /* Transmit Packet Process */
> + txptr->tdes0 = 0x8000; /* set owner bit to DM910X */
> + outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
> + dev->trans_start = jiffies; /* saved the time stamp */
>
>/* Point to next transmit free descriptor */
> - db->tx_insert_ptr = (struct tx_desc *) txptr->next_tx_desc;
> + txptr = (struct tx_desc *)txptr->next_tx_desc;
>
> - /* Transmit Packet Process */
> - if (db->tx_packet_cnt < TX_MAX_SEND_CNT) {
> - txptr->tdes0 = 0x8000; /* set owner bit to DM910X */
> - db->tx_packet_cnt++;/* Ready to send count */
> - outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
> - } else {
> - db->tx_queue_cnt++; /* queue the tx packet */
> - outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
> - }
> + if (txptr->tdes0 & 0x8000)
> + netif_stop_queue(dev);
>
> - /* Tx resource check */
> - if (db->tx_packet_cnt < TX_FREE_DESC_CNT)
> - netif_wake_queue(dev);
> + db->tx_insert_ptr = txptr;
> + db->tx_live_cnt++;
> +
> + spin_unlock_irq(&tp->lock);
>
>/* free this SKB */
>dev_kfree_skb(skb);
> +
>return 0;
> }
>
> @@ -713,12 +714,14 @@
>outl(0, ioaddr + DCR7);/* disable all interrupt
Re: [CFT] dmfe.c network driver update for 2.4
Tobias Ringstrom wrote: > > I have updated the dmfe.c network driver for 2.4.0-test by adding proper > locking (I hope), and also made transmission much efficient. > > I would appreciate any feedback from people using this driver, to confirm > that I did not break it. > > It would also be great if someone could take a look at the lock handling, > to confirm that is is correct and sufficient. Would you mind creating a separate patch that -just- correcting the SMP safety? That makes it much easier to review and apply, and then we can consider the other changes... Thanks, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
On Wed, 15 Nov 2000, Jeff Garzik wrote: > Tobias Ringstrom wrote: > > > > I have updated the dmfe.c network driver for 2.4.0-test by adding proper > > locking (I hope), and also made transmission much efficient. > > > > I would appreciate any feedback from people using this driver, to confirm > > that I did not break it. > > > > It would also be great if someone could take a look at the lock handling, > > to confirm that is is correct and sufficient. > > Would you mind creating a separate patch that -just- correcting the SMP > safety? That makes it much easier to review and apply, and then we can > consider the other changes... Such a patch will appear shortly. I and Frank Davis are currently merging our patches for dmfe.c. [Actually, I just added reasonable locks while my main goal was to improve performance. I did not realize that there was such a strong need for SMP safety (since it has been broken in that regard for a long time, without anyone fixing it).] /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
Tobias Ringstrom wrote: > On Wed, 15 Nov 2000, Jeff Garzik wrote: > > Tobias Ringstrom wrote: > > > I have updated the dmfe.c network driver for 2.4.0-test by adding proper > > > locking (I hope), and also made transmission much efficient. > > Would you mind creating a separate patch that -just- correcting the SMP > > safety? That makes it much easier to review and apply, and then we can > > consider the other changes... > Such a patch will appear shortly. I and Frank Davis are currently merging > our patches for dmfe.c. Thanks a bunch. > [Actually, I just added reasonable locks while my main goal was to improve > performance. I did not realize that there was such a strong need for SMP > safety (since it has been broken in that regard for a long time, without > anyone fixing it).] The kernel driver APIs are designed so that SMP and UP cases are equally high-performance, and portable beyond the x86 platform. Pretty much all ISA and PCI drivers need to be portable and SMP safe... if not so, it's a bug. That said, there is certainly more motivation to make a popular PCI driver is SMP safe than an older ISA driver. And portability is [IMHO] less of a priority than SMP safety, though it depends on the hardware being supported. Regards, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
On Thu, 16 Nov 2000, Jeff Garzik wrote: > The kernel driver APIs are designed so that SMP and UP cases are equally > high-performance, and portable beyond the x86 platform. > > Pretty much all ISA and PCI drivers need to be portable and SMP safe... > if not so, it's a bug. That said, there is certainly more motivation to > make a popular PCI driver is SMP safe than an older ISA driver. And > portability is [IMHO] less of a priority than SMP safety, though it > depends on the hardware being supported. How about adding an ifdef CONFIG_SMP then print ugly warning to all known SMP unsafe drivers? A message could be printed booth at compile and load time. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
I would rather fix those non-SMP compliant drivers to be SMP compliant, then keeping them 'broken'. Adding the print statements would only be a temporary solution. Regards, Frank --On Friday, November 17, 2000 10:20 AM +0100 Tobias Ringstrom > How about adding an ifdef CONFIG_SMP then print ugly warning to all known > SMP unsafe drivers? A message could be printed booth at compile and load > time. > > /Tobias > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
> --On Friday, November 17, 2000 10:20 AM +0100 Tobias Ringstrom > > How about adding an ifdef CONFIG_SMP then print ugly warning to all known > > SMP unsafe drivers? A message could be printed booth at compile and load > > time. Frank Davis wrote: > I would rather fix those non-SMP compliant drivers to be SMP compliant, > then keeping them 'broken'. Adding the print statements would only be a > temporary solution. Agreed. If people have SMP safety patches for net drivers, let me know... Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
On Fri, 17 Nov 2000, Frank Davis wrote: > > I would rather fix those non-SMP compliant drivers to be SMP compliant, > then keeping them 'broken'. Adding the print statements would only be a > temporary solution. Of course. This list of priorites is very natural, I think: 1. Working SMP driver 2. Broken SMP driver with a warning. 3. Broken SMP driver without a warning. (Even if "everyone" knows it is broken) It takes less than a minute to add such a warning, but it can take days or weeks to find someone to really fix the driver. That was my point. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
Tobias Ringstrom wrote: > > On Fri, 17 Nov 2000, Frank Davis wrote: > > > > I would rather fix those non-SMP compliant drivers to be SMP compliant, > > then keeping them 'broken'. Adding the print statements would only be a > > temporary solution. > > Of course. This list of priorites is very natural, I think: > > 1. Working SMP driver > 2. Broken SMP driver with a warning. > 3. Broken SMP driver without a warning. (Even if "everyone" knows it >is broken) > > It takes less than a minute to add such a warning, but it can take days > or weeks to find someone to really fix the driver. That was my point. Marking them with a #warning is fine with me. -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
[Jeff Garzik] > Pretty much all ISA and PCI drivers need to be portable and SMP > safe... if not so, it's a bug. That said, there is certainly more > motivation to make a popular PCI driver is SMP safe than an older ISA > driver. Usually, but you never know... "o SMP optimised 3c501" -- 2.1.132ac2 changelog (: Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
