linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Metcalf <cmetcalf@tilera.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: David Miller <davem@davemloft.net>, <arnd@arndb.de>,
	<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH v5] tilegx network driver: initial support
Date: Sun, 20 May 2012 12:35:01 -0400	[thread overview]
Message-ID: <4FB91D35.3040000@tilera.com> (raw)
In-Reply-To: <1336744445.2874.57.camel@bwh-desktop.uk.solarflarecom.com>

On 5/11/2012 9:54 AM, Ben Hutchings wrote:
> Here's another very incomplete review for you.

Thanks, I (we) appreciate it!

>> +/* Define to support GSO. */
>> +#undef TILE_NET_GSO
> GSO is always enabled by the networking core.
>
>> +/* Define to support TSO. */
>> +#define TILE_NET_TSO
> No, put NETIF_F_TSO in hw_features so it can be switched at run-time.

We already had that; the TSO define was just to decide whether the driver
would even offer TSO support at all.  But on reflection it seems pointless
not to offer TSO, so I've made it true unconditionally and deleted the
define.  Similarly I got rid of the (totally pointless) GSO define and let
the core control whether it switches GSO on or not.

We are looking at GRO support for a following change, but obviously we need
to set up ethtool_ops for that first, so we'll be doing that as well.

>> +/* Use 3000 to enable the Linux Traffic Control (QoS) layer, else 0. */
>> +#define TILE_NET_TX_QUEUE_LEN 0
> This can be changed through sysfs, so there is no need for a compile-
> time option.

Fair enough, and in practice we don't change this default anyway, so I
eliminated it.

>> +/* Define to dump packets (prints out the whole packet on tx and rx). */
>> +#undef TILE_NET_DUMP_PACKETS
> Should really be controlled through a 'debug' module parameter (see
> netif_msg_init(), netif_msg_pktdata(), etc.)

We almost never use this functionality anyway, so for now, I've just
removed it.  If we want to reintroduce something like it, we'll use the
netif_msg stuff.

>> +	/* Reserve slots, or return NETDEV_TX_BUSY if "full". */
>> +	slot = gxio_mpipe_equeue_try_reserve(equeue, num_frags);
>> +	if (slot < 0) {
>> +		local_irq_restore(irqflags);
>> +		/* ISSUE: "Virtual device xxx asks to queue packet". */
>> +		return NETDEV_TX_BUSY;
>> +	}
> You're supposed to stop queues when they're full.  And since that state
> appears to be per-CPU, I think this device needs to be multiqueue with
> one TX queue per CPU and ndo_select_queue defined accordingly.
>
> [...]
>
> I'm not convinced you should be processing completions here at all.  But
> certainly you should have stopped the queue earlier rather than having
> to wait here.

This is a larger issue.  We are working on improving performance in the
driver overall, and how we handle per-cpu or global queueing, how we stop
and restart the driver, etc., will be part of it.  (The underlying mpipe
resources are not per-cpu, so it may or may not make sense to have the
driver believe it's multiqueue.)  I added some placeholder comments and a
reference to our internal bug ID on this issue.

> You mustn't treat random fields to atomic_t.  For one thing, atomic_t
> contains an int while stats are unsigned long...
>
> Also, you're adding cache contention between all your CPUs here.  You
> should maintain these stats per-CPU and then sum them in
> tile_net_get_stats().  Then you can just use ordinary additions.

Oops, you're right that atomic_t is the wrong size.  What I've done is
switch to atomic_long_t, but moved the cast to a separate
tile_net_stats_add() function that has a BUILD_BUG_ON() to validate that
the sizes match, and also a long comment explaining why tilegx's memory
network architecture makes atomic adds exactly the right kind of thing to
do here.  It's easy to forget that 99% of the world has a model of atomics
based on the Intel architecture.

> [...]
>> +/* Ioctl commands. */
>> +static int tile_net_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
>> +{
>> +	return -EOPNOTSUPP;
>> +}
> So why define it at all?

Because a following patch (not yet posted to LKML) adds support for
SIOCSHWTSTAMP and the ioctl was originally written that way to put the
framework in place.

The few suggestions I didn't respond to directly where pretty
straightforward and I just implemented them as you suggested.

Thanks again!  The revised patch will follow momentarily.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com


  parent reply	other threads:[~2012-05-20 16:35 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-04 20:39 [PATCH 0/6] arch/tile: provide tilegx networking support Chris Metcalf
2012-04-04 20:39 ` [PATCH 1/6] arch/tile: introduce GXIO IORPC framework for tilegx Chris Metcalf
2012-04-04 20:58 ` [PATCH 4/6] arch/tile: common DMA code for the GXIO IORPC subsystem Chris Metcalf
2012-04-06 17:41 ` [PATCH 2/6] arch/tile: fix set_pte() to properly handle kernel MMIO mappings Chris Metcalf
2012-04-06 17:52 ` [PATCH 3/6] arch/tile: support MMIO-based readb/writeb etc Chris Metcalf
2012-04-09 13:24   ` Arnd Bergmann
2012-04-09 20:53     ` Chris Metcalf
2012-04-06 20:38 ` [PATCH 5/6] arch/tile: provide kernel support for the tilegx mPIPE shim Chris Metcalf
2012-04-09 13:34   ` Arnd Bergmann
2012-04-09 21:04     ` Chris Metcalf
2012-04-06 20:42 ` [PATCH 6/6] tilegx network driver: initial support Chris Metcalf
2012-04-09 13:49   ` Arnd Bergmann
2012-04-09 21:30     ` Chris Metcalf
2012-04-10 10:42       ` Arnd Bergmann
2012-04-12 23:23         ` Chris Metcalf
2012-04-13 10:34           ` Arnd Bergmann
2012-04-28 22:07             ` Chris Metcalf
2012-04-04 20:39               ` [PATCH v2 0/6] arch/tile: networking support for tilegx Chris Metcalf
2012-04-04 20:39                 ` [PATCH v2 1/6] arch/tile: introduce GXIO IORPC framework " Chris Metcalf
2012-04-04 20:58                 ` [PATCH v2 3/6] arch/tile: common DMA code for the GXIO IORPC subsystem Chris Metcalf
2012-04-06 17:52                 ` [PATCH v2 2/6] arch/tile: support MMIO-based readb/writeb etc Chris Metcalf
2012-04-06 20:38                 ` [PATCH v2 4/6] arch/tile: provide kernel support for the tilegx mPIPE shim Chris Metcalf
2012-04-06 20:42                 ` [PATCH v2 6/6] tilegx network driver: initial support Chris Metcalf
2012-04-30 14:35                   ` Arnd Bergmann
2001-09-17  4:00                     ` [PATCH v3] " Chris Metcalf
2012-05-03  5:41                       ` David Miller
2012-05-03 15:45                         ` Chris Metcalf
2012-05-03 17:07                           ` David Miller
2012-05-03 17:25                             ` Chris Metcalf
2012-05-03 16:41                         ` [PATCH v4] " Chris Metcalf
2012-05-04  6:42                           ` David Miller
2012-05-09 10:42                             ` [PATCH v5] " Chris Metcalf
2012-05-11 13:54                               ` Ben Hutchings
2012-05-20  4:42                                 ` [PATCH v6] " Chris Metcalf
2012-05-20 20:55                                   ` David Miller
2012-05-23 20:42                                     ` [PATCH v7] " Chris Metcalf
2012-05-24  4:31                                       ` David Miller
2012-05-25 14:42                                         ` [PATCH v8] " Chris Metcalf
2012-06-04 20:12                                           ` [PATCH v9] " Chris Metcalf
2012-06-06 16:41                                             ` David Miller
2012-06-06 17:31                                             ` Eric Dumazet
2012-06-06 17:40                                             ` Eric Dumazet
2012-06-06 18:36                                               ` Chris Metcalf
2012-06-06 18:54                                                 ` David Miller
2001-09-17  4:00                                                   ` [PATCH v10] " Chris Metcalf
2012-04-06 20:42                                                   ` Chris Metcalf
2012-06-07 20:39                                                     ` David Miller
2012-06-07 20:44                                                       ` Chris Metcalf
2012-06-07 20:47                                                         ` Chris Metcalf
2012-06-07 20:50                                                         ` Ben Hutchings
2012-06-07 20:52                                                     ` Joe Perches
2012-06-07 20:45                                                   ` Chris Metcalf
2012-06-12  0:03                                                     ` David Miller
2012-06-12 13:14                                                       ` Chris Metcalf
2012-06-06 18:10                                             ` [PATCH v9] " Eric Dumazet
2012-06-06 18:17                                               ` David Miller
2012-06-06 18:19                                               ` Ben Hutchings
2012-05-20 16:35                                 ` Chris Metcalf [this message]
2012-04-28 19:41                 ` [PATCH v2 5/6] arch/tile: break out the "csum a long" function to <asm/checksum.h> Chris Metcalf
2012-04-29 11:15               ` [PATCH 6/6] tilegx network driver: initial support Arnd Bergmann
2012-04-15 23:06         ` Chris Metcalf

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=4FB91D35.3040000@tilera.com \
    --to=cmetcalf@tilera.com \
    --cc=arnd@arndb.de \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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).