linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Einon <mark.einon@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: gregkh@linuxfoundation.org, sfr@canb.auug.org.au,
	netdev@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-kernel@vger.kernel.org, dan.carpenter@oracle.com
Subject: Re: [RFC PATCH v4 linux-next] et131x: Promote staging et131x driver to drivers/net
Date: Tue, 29 Jan 2013 12:47:14 +0000	[thread overview]
Message-ID: <CANK3SE2kiV0gPRaM0Y-eHs0cxXs8ZgZK=p=eNZnENOdXir7rNA@mail.gmail.com> (raw)
In-Reply-To: <20130128.231057.57111832691623178.davem@davemloft.net>

On 29 January 2013 04:10, David Miller <davem@davemloft.net> wrote:
> From: Mark Einon <mark.einon@gmail.com>
> Date: Wed, 23 Jan 2013 16:24:38 +0000
>
>> +endif # NET_VENDOR_AGERE
>> +
>
> Trailing empty line, delete it.
>
>> @@ -0,0 +1,6 @@
>> +#
>> +# Makefile for the Agere ET-131x ethernet driver
>> +#
>> +
>> +obj-$(CONFIG_ET131X) += et131x.o
>> +
>
> Likewise, get rid of this trailing empty line.
>
>> +     /* Spinlocks */
>> +     spinlock_t lock;
>> +
>> +     spinlock_t tcb_send_qlock;
>> +     spinlock_t tcb_ready_qlock;
>> +     spinlock_t send_hw_lock;
>> +
>> +     spinlock_t rcv_lock;
>> +     spinlock_t rcv_pend_lock;
>> +     spinlock_t fbr_lock;
>> +
>> +     spinlock_t phy_lock;
>
> Do you really need _8_ spinlocks in an ethernet driver?  To me that's
> way over the top and excessive.
>
> The most recent driver I've written, for the 10Gbit Sun NIU parts,
> has only one spinlock.
>
>> +     /* Determine if this is a multicast packet coming in */
>
> What in the world are you doing in this huge code block?
>
> Such much complexity, multicast list iteration, etc. just to get some
> statistics correct?  This stuff is going to run on every multicast
> packet receive.
>
> No other driver does crap like this, get rid of this stuff.
>
>> +     skb->dev = adapter->netdev;
>> +     skb->protocol = eth_type_trans(skb, adapter->netdev);
>
> eth_type_trans() sets skb->dev, you don't need to duplicate that.
>
>> +     netif_rx_ni(skb);
>
> Why isn't this driver supporting NAPI?  If you're going to put this
> much time into a driver, use the best interfaces for event processing
> rather than something that might have been appropriate in a new driver
> two decades ago.
>
>> +static int et131x_tx(struct sk_buff *skb, struct net_device *netdev)
>> +{
>> +     int status = 0;
>> +     struct et131x_adapter *adapter = netdev_priv(netdev);
>> +
>> +     /* stop the queue if it's getting full */
>> +     if (adapter->tx_ring.used >= NUM_TCB - 1 &&
>> +         !netif_queue_stopped(netdev))
>> +             netif_stop_queue(netdev);
>> +
>> +     /* Save the timestamp for the TX timeout watchdog */
>> +     netdev->trans_start = jiffies;
>> +
>> +     /* Call the device-specific data Tx routine */
>> +     status = et131x_send_packets(skb, netdev);
>> +
>> +     /* Check status and manage the netif queue if necessary */
>> +     if (status != 0) {
>> +             if (status == -ENOMEM)
>> +                     status = NETDEV_TX_BUSY;
>> +             else
>> +                     status = NETDEV_TX_OK;
>> +     }
>> +     return status;
>> +}
>
> Returning NETDEV_TX_BUSY is an error, no driver should ever return
> that status under normal circumstances.  Some drivers return it
> when internal consistency checks fail, but that indicates a driver
> bug rather than a normal condition.
>
> Memory allocation erorrs do not denote NETDEV_TX_BUSY, simply drop
> the packet silently with kfree_skb() and return NETDEV_TX_OK.
>
> That's about enough for me, this driver still needs a lot of work
> and is far from being ready to move out of staging.

Thanks for taking the time to give feedback. I'll update the TODO list.

Cheers,

Mark

      reply	other threads:[~2013-01-29 12:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-18 20:40 [RFC PATCH linux-next] et131x: Promote staging et131x driver to drivers/net Mark Einon
2013-01-18 22:57 ` Greg KH
2013-01-19 11:03   ` Dan Carpenter
2013-01-19 11:48     ` [PATCH] staging: et131x: Fix all sparse warnings Mark Einon
2013-01-21 23:44     ` [RFC PATCH linux-next] et131x: Promote staging et131x driver to drivers/net Mark Einon
2013-01-22  6:20       ` Dan Carpenter
2013-01-23 10:10 ` [RFC PATCH v2 " Mark Einon
2013-01-23 10:31   ` Dan Carpenter
2013-01-23 11:31     ` Mark Einon
2013-01-23 12:45   ` [RFC PATCH v3 " Mark Einon
2013-01-23 14:32     ` Greg KH
2013-01-23 14:51       ` Mark Einon
2013-01-23 16:24     ` [RFC PATCH v4 " Mark Einon
2013-01-29  4:10       ` David Miller
2013-01-29 12:47         ` Mark Einon [this message]

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='CANK3SE2kiV0gPRaM0Y-eHs0cxXs8ZgZK=p=eNZnENOdXir7rNA@mail.gmail.com' \
    --to=mark.einon@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=davem@davemloft.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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).