* Re: [PATCH net-next 3/3] cxgb4vf: add maintainer entry for cxgb4vf
From: David Miller @ 2010-07-20 20:23 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <201007200859.57111.leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Tue, 20 Jul 2010 08:59:56 -0700
>>From 7710873beb494b46333fdf9841b4a117bdb66a5a Mon Sep 17 00:00:00 2001
> From: Casey Leedom <leedom@chelsio.com>
> Date: Mon, 19 Jul 2010 17:55:33 -0700
> Subject: [PATCH net-next 3/3] cxgb4vf: add maintainer entry for cxgb4vf
>
> Adding myself as the official maintainer of the Chelsio T4 Virtual function
> Driver (cxgb4vf).
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-20 20:18 UTC (permalink / raw)
To: sassmann
Cc: abadea, bhutchings, netdev, linux-kernel, gospo, gregory.v.rose,
alexander.h.duyck, leedom, harald
In-Reply-To: <4C4593DA.9040207@redhat.com>
From: Stefan Assmann <sassmann@redhat.com>
Date: Tue, 20 Jul 2010 14:17:30 +0200
> On 20.07.2010 13:58, Alex Badea wrote:
>> Hi,
>>
>> On 07/20/2010 02:47 PM, Stefan Assmann wrote:
>>>> What about devices that 'steal' MAC addresses from slave devices?
>>
>> Might I suggest an attribute such as "address_type", which could report
>> "permanent", "random", "stolen", or something else in the future?
>
> In case there's demand for such a multi-purpose attribute I see no
> reason to object. More thoughts on this?
I think this is a great idea.
Now it makes sense to use a new 'u8' in struct netdevice or similar to
store this, since we'll have more than a boolean here.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-20 20:17 UTC (permalink / raw)
To: bhutchings
Cc: sassmann, netdev, linux-kernel, gospo, gregory.v.rose,
alexander.h.duyck, leedom, harald
In-Reply-To: <1279636194.2110.45.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 20 Jul 2010 15:29:54 +0100
> On Tue, 2010-07-20 at 14:41 +0200, Stefan Assmann wrote:
>> Btw, the driver itself could also alter the flag. Then we'd have a well
>> defined way of setting a stable address.
>
> The driver can't know whether an address assigned by the user is stable.
If userspace can somehow obtain a persistent address, it can kick
udev too.
I really don't see any real value provided by letting userspace mess
with this. Because the permanence communicated in this value is from
the perspective of the kernel driver, it's really therefore about the
thing that's in ->perm_addr[] not what happens to be in ->addr[] right
now.
^ permalink raw reply
* Re: [PATCH] LSM: Add post accept() hook.
From: Paul Moore @ 2010-07-20 19:52 UTC (permalink / raw)
To: Tetsuo Handa
Cc: davem, eric.dumazet, jmorris, sam, serge, netdev,
linux-security-module
In-Reply-To: <201007200136.o6K1aVc5015269@www262.sakura.ne.jp>
On Monday, July 19, 2010 09:36:31 pm Tetsuo Handa wrote:
> Paul Moore wrote:
> > I think you need to show how you plan to use this hook in an LSM before
> > we can consider merging it with mainline. What you are proposing here
> > is giving an LSM the ability to drop a connection _after_ allowing it to
> > be established in the first place; this seems very wrong to me and I
> > want to make sure everyone else is aware of that before accepting this
> > code into the kernel. I understand that TOMOYO's security model does
> > not allow it to reject incoming connections at the beginning of the
> > connection request like some of the LSMs currently in use, but I'm just
> > not very happy with the idea of finishing a connection handshake only to
> > later drop the connection on the floor.
>
> Yes. I'm planning to use security_socket_post_accept() for two purposes.
>
> One is for dropping connections from unwanted hosts. Administrators define
> policy before enabling enforcing mode (the mode which connections are
> dropped if operation was not granted by policy). Administrators specify
> acceptable hosts (i.e. hosts which this host needs to communicate with)
> and unacceptable hosts (i.e. hosts which this host needn't to communicate
> with).
You can enforce per-host access controls without the need for a post-accept()
hooks, e.g. security_sock_rcv_skb() and the netfilter hooks
(NF_INET_POST_ROUTING, NF_INET_FORWARD, NF_INET_LOCAL_OUT). Or are you
interested in controlling which hosts an _application_ can communicate with?
> Dropping connections would happen if some process was hijacked and the
> process attempted to communicate with other processes using TCP
> connections. But dropping connections should not happen in normal
> circumstance.
It doesn't matter if dropping connections is normal or not, what matters is
that it can happen.
> The other is for updating process's state variable upon accept() operation.
> LKM version of TOMOYO has per a task_struct variable that is used for
> implementing stateful permissions. (As of now, not implemented for LSM
> version of TOMOYO.)
I'm open to re-introducing a post-accept() hook that does not have a return
value, in other words, a hook that can only be used to update LSM state and
not affect the connection. Although I do think you could probably achieve the
same thing using some of the existing LSM hooks (look at how SELinux updates
its state upon accept()) but that is something you would have to look it and
see if it works for TOMOYO.
--
paul moore
linux @ hp
^ permalink raw reply
* Re: netfilter/iptables stopped logging 2.6.35-rc
From: auto401300 @ 2010-07-20 19:22 UTC (permalink / raw)
To: maciej.rutecki; +Cc: netdev, linux-kernel
On Tue, 20 Jul 2010 15:51:03 +0300 Maciej Rutecki
<maciej.rutecki@gmail.com> wrote:
>On sobota, 17 lipca 2010 o 09:20:36 auto401300@hushmail.com wrote:
>> Hi!
>>
>> Has something broken with netfilter/iptables logging in 2.6.35-
>rc,
>> or is there something new I should set in .config since .34?
>>
>>
>> I just verified that if I boot .34 and ping the pc it does
>logging:
>>
>> Jul 17 09:42:49 xxxxx kernel: Linux version 2.6.34-ab
>(root@xxxxx)
>> (gcc version 4.4.4 (Debian 4.4.4-1) ) #1 SMP PREEMPT Mon May 17
>> 09:15
>>
>> :15 EEST 2010
>>
>> ....
>> Jul 17 09:44:52 xxxxx kernel: DENY in: IN=eth0 OUT= MAC=xxxxx
>> SRC=xxxxx DST=xxxxx LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=38945
>> PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=256
>>
>>
>> but if I boot .35-rc4 and ping:
>>
>> Jul 17 09:48:08 xxxxx kernel: Linux version 2.6.35-rc4-aa
>> (root@xxxxx) (gcc version 4.4.4 (Debian 4.4.4-6) ) #1 SMP
>PREEMPT
>> Mon Jul 5 15:22:02 EEST 2010
>> ....
>> nothing from iptables in log
>>
>>
>> userspace is same, only booted different kernel versions
>
>I created a Bugzilla entry at
>https://bugzilla.kernel.org/show_bug.cgi?id=16423
>for your bug report, please add your address to the CC list in
>there, thanks!
>
>--
>Maciej Rutecki
>http://www.maciek.unixy.pl
I just thought that whole initramfs may be also different and tried
to compile
.34 again to test if it still does iptables logging with current
toolchain but
just now debian kernel-package is broken due to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589700
I will try again when that is fixed
thanks.
^ permalink raw reply
* Re: [PATCH] net: Add batman-adv meshing protocol
From: Sven Eckelmann @ 2010-07-20 19:21 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
siwu-MaAgPAbsBIVS8oHt8HbXEIQuADTiUCJX, Marek Lindner,
David Miller, Abraham Arce
In-Reply-To: <1279652233.2110.51.camel-xQnnTUlwzDrdvaEqJLTMTA9jg9n5Vt1AMm0uRHvK7Nw@public.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 1533 bytes --]
Ben Hutchings wrote:
> On Tue, 2010-07-20 at 20:49 +0200, Sven Eckelmann wrote:
> > Abraham Arce wrote:
> > > Minor comments...
> > >
> > > 1. Is it ok to have a README in drivers directory? why not moving it
> > > to Documentation/networking?
> >
> > Thanks, I will check if Documentation/networking is a better place.
> >
> > > 2. Compilation error, one extra arguments passed
> > >
> > > - stats = (struct net_device_stats *)dev_get_stats(skb->dev, &temp);
> > > + stats = (struct net_device_stats *)dev_get_stats(skb->dev, &temp);
> > >
> > > LD kernel/built-in.o
> > >
> > > net/batman-adv/hard-interface.c: In function 'batman_skb_recv':
> > > net/batman-adv/hard-interface.c:482: error: too many arguments to
> > > function 'dev_get_stats'
> > > make[2]: *** [net/batman-adv/hard-interface.o] Error 1
> > > make[2]: *** Waiting for unfinished jobs....
> > > make[1]: *** [net/batman-adv] Error 2
> > > make: *** [net] Error 2
> >
> > Do you use linux-next or net-next-2.6? Because this is needed to get it
> > compiled as dev_get_stats was changed some time ago (commit
> > 28172739f0a276eb8d6ca917b3974c2edb036da3), but this is not part of
> > 2.6.35.
>
> Even so, that cast is a bug following commit
> 3cfde79c6c7c8002375c4a8e5be7f602fbb9675d.
I've only noticed the changes to the batman-adv code in staging through
28172739f0a276eb8d6ca917b3974c2edb036da3, but missed that more is needed with
the above mentioned one. Thanks a lot for the hint.
Best regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH] net: Add batman-adv meshing protocol
From: Ben Hutchings @ 2010-07-20 18:57 UTC (permalink / raw)
To: Sven Eckelmann
Cc: Abraham Arce, Marek Lindner, b.a.t.m.a.n, David Miller, netdev,
siwu
In-Reply-To: <201007202049.31530.sven.eckelmann@gmx.de>
On Tue, 2010-07-20 at 20:49 +0200, Sven Eckelmann wrote:
> Abraham Arce wrote:
> > Minor comments...
> >
> > 1. Is it ok to have a README in drivers directory? why not moving it
> > to Documentation/networking?
>
> Thanks, I will check if Documentation/networking is a better place.
>
> > 2. Compilation error, one extra arguments passed
> >
> > - stats = (struct net_device_stats *)dev_get_stats(skb->dev, &temp);
> > + stats = (struct net_device_stats *)dev_get_stats(skb->dev, &temp);
> >
> > LD kernel/built-in.o
> > net/batman-adv/hard-interface.c: In function 'batman_skb_recv':
> > net/batman-adv/hard-interface.c:482: error: too many arguments to
> > function 'dev_get_stats'
> > make[2]: *** [net/batman-adv/hard-interface.o] Error 1
> > make[2]: *** Waiting for unfinished jobs....
> > make[1]: *** [net/batman-adv] Error 2
> > make: *** [net] Error 2
>
> Do you use linux-next or net-next-2.6? Because this is needed to get it
> compiled as dev_get_stats was changed some time ago (commit
> 28172739f0a276eb8d6ca917b3974c2edb036da3), but this is not part of 2.6.35.
Even so, that cast is a bug following commit
3cfde79c6c7c8002375c4a8e5be7f602fbb9675d.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: Add batman-adv meshing protocol
From: Sven Eckelmann @ 2010-07-20 18:49 UTC (permalink / raw)
To: Abraham Arce
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, Marek Lindner,
David Miller, siwu-MaAgPAbsBIVS8oHt8HbXEIQuADTiUCJX
In-Reply-To: <AANLkTim4QSjgC2BbrEJEpefQahbkSgaRPPfJ-N0aPL-E-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 1034 bytes --]
Abraham Arce wrote:
> Minor comments...
>
> 1. Is it ok to have a README in drivers directory? why not moving it
> to Documentation/networking?
Thanks, I will check if Documentation/networking is a better place.
> 2. Compilation error, one extra arguments passed
>
> - stats = (struct net_device_stats *)dev_get_stats(skb->dev, &temp);
> + stats = (struct net_device_stats *)dev_get_stats(skb->dev, &temp);
>
> LD kernel/built-in.o
> net/batman-adv/hard-interface.c: In function 'batman_skb_recv':
> net/batman-adv/hard-interface.c:482: error: too many arguments to
> function 'dev_get_stats'
> make[2]: *** [net/batman-adv/hard-interface.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [net/batman-adv] Error 2
> make: *** [net] Error 2
Do you use linux-next or net-next-2.6? Because this is needed to get it
compiled as dev_get_stats was changed some time ago (commit
28172739f0a276eb8d6ca917b3974c2edb036da3), but this is not part of 2.6.35.
Best regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH] net: Add batman-adv meshing protocol
From: Abraham Arce @ 2010-07-20 18:41 UTC (permalink / raw)
To: Marek Lindner; +Cc: b.a.t.m.a.n, David Miller, sven.eckelmann, netdev, siwu
In-Reply-To: <201007202023.17883.lindner_marek@yahoo.de>
Hi,
On Tue, Jul 20, 2010 at 1:23 PM, Marek Lindner <lindner_marek@yahoo.de> wrote:
> On Tuesday, July 20, 2010 18:59:28 David Miller wrote:
>> Whoever you leave it to, this needs to be fixed up before this
>> code can be integrated. So if those people are not active or
>> don't have time, you very much should consider the reality that
>> you might have to do these fixups yourself.
>
> No worries - we are quite alive and follow the discussion closely. The raised
> issues will be addressed pretty soon.
>
> @Sven: I think you do a great job integrating all those patches and trees.
> Your helping hand would be really missed. :)
Minor comments...
1. Is it ok to have a README in drivers directory? why not moving it
to Documentation/networking?
2. Compilation error, one extra arguments passed
- stats = (struct net_device_stats *)dev_get_stats(skb->dev, &temp);
+ stats = (struct net_device_stats *)dev_get_stats(skb->dev, &temp);
LD kernel/built-in.o
net/batman-adv/hard-interface.c: In function 'batman_skb_recv':
net/batman-adv/hard-interface.c:482: error: too many arguments to
function 'dev_get_stats'
make[2]: *** [net/batman-adv/hard-interface.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [net/batman-adv] Error 2
make: *** [net] Error 2
Best Regards
Abraham
^ permalink raw reply
* Re: [PATCH] net: Add batman-adv meshing protocol
From: Marek Lindner @ 2010-07-20 18:23 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller,
siwu-MaAgPAbsBIVS8oHt8HbXEIQuADTiUCJX
In-Reply-To: <20100720.095928.113690788.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tuesday, July 20, 2010 18:59:28 David Miller wrote:
> Whoever you leave it to, this needs to be fixed up before this
> code can be integrated. So if those people are not active or
> don't have time, you very much should consider the reality that
> you might have to do these fixups yourself.
No worries - we are quite alive and follow the discussion closely. The raised
issues will be addressed pretty soon.
@Sven: I think you do a great job integrating all those patches and trees.
Your helping hand would be really missed. :)
Regards,
Marek
^ permalink raw reply
* Re: [PATCH net-next] drivers/acpi/acpica/utmisc.c: Use printk extension %pV
From: Joe Perches @ 2010-07-20 18:16 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Len Brown, linux-acpi, linux-kernel, netdev, David Miller
In-Reply-To: <201007201008.04496.bjorn.helgaas@hp.com>
On Tue, 2010-07-20 at 10:08 -0600, Bjorn Helgaas wrote:
> On Monday, July 19, 2010 11:06:07 pm Joe Perches wrote:
> > Consolidates the printk messages to a single
> > call so the messages can not be interleaved.
> >
> > Reduces text a bit.
> >
> > $ size drivers/acpi/acpica/utmisc.o.*
> > text data bss dec hex filename
> > 7822 56 1832 9710 25ee drivers/acpi/acpica/utmisc.o.old
> > 7748 56 1736 9540 2544 drivers/acpi/acpica/utmisc.o.new
> >
> > Depends on net-next commit 7db6f5fb65a82af03229eef104dc9899c5eecf33
> > (vsprintf: Recursive vsnprintf: Add "%pV", struct va_format)
>
> drivers/acpi/acpica/utmisc.c is part of the ACPI CA and is used in
> several different OSes, but %pV sounds like a Linux-specific feature,
> so I don't see how this patch can work.
Well, maybe something like this then.
It still reduces overall size a little bit, but less.
$ size drivers/acpi/acpica/utmisc.o
text data bss dec hex filename
7816 56 1784 9656 25b8 drivers/acpi/acpica/utmisc.o
I'm not sure that utmisc.c is the right place for an #ifdef though.
---
drivers/acpi/acpica/utmisc.c | 76 +++++++++++++++++++++++++++---------------
1 files changed, 49 insertions(+), 27 deletions(-)
diff --git a/drivers/acpi/acpica/utmisc.c b/drivers/acpi/acpica/utmisc.c
index e8d0724..874e4d2 100644
--- a/drivers/acpi/acpica/utmisc.c
+++ b/drivers/acpi/acpica/utmisc.c
@@ -51,10 +51,45 @@
ACPI_MODULE_NAME("utmisc")
/*
- * Common suffix for messages
+ * Single line messages, adds a newline after message
*/
-#define ACPI_COMMON_MSG_SUFFIX \
- acpi_os_printf(" (%8.8X/%s-%u)\n", ACPI_CA_VERSION, module_name, line_number)
+
+static void ACPI_PRINTF_LIKE(5)
+acpi_put_message(const char *module_name, u32 line_number,
+ const char *fmt, va_list *args, const char *message, ...)
+{
+#ifdef __KERNEL__
+ va_list message_args;
+ struct va_format vaf1;
+ struct va_format vaf2;
+
+ va_start(message_args, message);
+ vaf1.fmt = message;
+ vaf1.va = &message_args;
+ vaf2.fmt = fmt;
+ vaf2.va = args;
+ if (module_name)
+ acpi_os_printf("%pV%pV (%8.8X/%s-%u)\n",
+ &vaf1, &vaf2,
+ ACPI_CA_VERSION, module_name, line_number);
+ else
+ acpi_os_printf("%pV%pV\n", &vaf1, &vaf2);
+ va_end(message_args);
+#else
+ va_list message_args;
+
+ va_start(message_args, message);
+ acpi_os_vprintf(message, message_args);
+ acpi_os_vprintf(fmt, *args);
+ if (module_name)
+ acpi_os_printf(" (%8.8X/%s-%u)\n",
+ ACPI_CA_VERSION, module_name, line_number);
+ else
+ acpi_os_printf("\n");
+ va_end(message_args);
+#endif
+}
+
/*******************************************************************************
*
* FUNCTION: acpi_ut_validate_exception
@@ -1064,11 +1099,9 @@ acpi_error(const char *module_name, u32 line_number, const char *format, ...)
{
va_list args;
- acpi_os_printf("ACPI Error: ");
-
va_start(args, format);
- acpi_os_vprintf(format, args);
- ACPI_COMMON_MSG_SUFFIX;
+ acpi_put_message(module_name, line_number, format, &args,
+ "ACPI Error: ");
va_end(args);
}
@@ -1078,11 +1111,9 @@ acpi_exception(const char *module_name,
{
va_list args;
- acpi_os_printf("ACPI Exception: %s, ", acpi_format_exception(status));
-
va_start(args, format);
- acpi_os_vprintf(format, args);
- ACPI_COMMON_MSG_SUFFIX;
+ acpi_put_message(module_name, line_number, format, &args,
+ "ACPI Exception: %s, ", acpi_format_exception(status));
va_end(args);
}
@@ -1091,11 +1122,9 @@ acpi_warning(const char *module_name, u32 line_number, const char *format, ...)
{
va_list args;
- acpi_os_printf("ACPI Warning: ");
-
va_start(args, format);
- acpi_os_vprintf(format, args);
- ACPI_COMMON_MSG_SUFFIX;
+ acpi_put_message(module_name, line_number, format, &args,
+ "ACPI Warning: ");
va_end(args);
}
@@ -1104,11 +1133,8 @@ acpi_info(const char *module_name, u32 line_number, const char *format, ...)
{
va_list args;
- acpi_os_printf("ACPI: ");
-
va_start(args, format);
- acpi_os_vprintf(format, args);
- acpi_os_printf("\n");
+ acpi_put_message(NULL, 0, format, &args, "ACPI: ");
va_end(args);
}
@@ -1152,11 +1178,9 @@ acpi_ut_predefined_warning(const char *module_name,
return;
}
- acpi_os_printf("ACPI Warning for %s: ", pathname);
-
va_start(args, format);
- acpi_os_vprintf(format, args);
- ACPI_COMMON_MSG_SUFFIX;
+ acpi_put_message(module_name, line_number, format, &args,
+ "ACPI Warning for %s: ", pathname);
va_end(args);
}
@@ -1194,10 +1218,8 @@ acpi_ut_predefined_info(const char *module_name,
return;
}
- acpi_os_printf("ACPI Info for %s: ", pathname);
-
va_start(args, format);
- acpi_os_vprintf(format, args);
- ACPI_COMMON_MSG_SUFFIX;
+ acpi_put_message(module_name, line_number, format, &args,
+ "ACPI Info for %s: ", pathname);
va_end(args);
}
^ permalink raw reply related
* [PATCH net-next-2.6] ixgbe: fix ethtool stats
From: Eric Dumazet @ 2010-07-20 17:28 UTC (permalink / raw)
To: Jeff Kirsher, David Miller; +Cc: Jesse Brandeburg, PJ Waskiewicz, netdev
Note : I am currently unable to test following patch, could you please
Intel guys test it and Ack (or Nack) it ?
Thanks !
[PATCH net-next-2.6] ixgbe: fix ethtool stats
In latest changes about 64bit stats on 32bit arches,
[commit 28172739f0a276eb8 (net: fix 64 bit counters on 32 bit arches)],
I missed ixgbe uses a bit of magic in its ixgbe_gstrings_stats
definition.
IXGBE_NETDEV_STAT() must now assume offsets relative to
rtnl_link_stats64, not relative do dev->stats.
As a bonus, we also get 64bit stats on ethtool -S
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/ixgbe/ixgbe_ethtool.c | 42 ++++++++++++++--------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index da54b38..dcebc82 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -54,14 +54,14 @@ struct ixgbe_stats {
sizeof(((struct ixgbe_adapter *)0)->m), \
offsetof(struct ixgbe_adapter, m)
#define IXGBE_NETDEV_STAT(m) NETDEV_STATS, \
- sizeof(((struct net_device *)0)->m), \
- offsetof(struct net_device, m) - offsetof(struct net_device, stats)
+ sizeof(((struct rtnl_link_stats64 *)0)->m), \
+ offsetof(struct rtnl_link_stats64, m)
static struct ixgbe_stats ixgbe_gstrings_stats[] = {
- {"rx_packets", IXGBE_NETDEV_STAT(stats.rx_packets)},
- {"tx_packets", IXGBE_NETDEV_STAT(stats.tx_packets)},
- {"rx_bytes", IXGBE_NETDEV_STAT(stats.rx_bytes)},
- {"tx_bytes", IXGBE_NETDEV_STAT(stats.tx_bytes)},
+ {"rx_packets", IXGBE_NETDEV_STAT(rx_packets)},
+ {"tx_packets", IXGBE_NETDEV_STAT(tx_packets)},
+ {"rx_bytes", IXGBE_NETDEV_STAT(rx_bytes)},
+ {"tx_bytes", IXGBE_NETDEV_STAT(tx_bytes)},
{"rx_pkts_nic", IXGBE_STAT(stats.gprc)},
{"tx_pkts_nic", IXGBE_STAT(stats.gptc)},
{"rx_bytes_nic", IXGBE_STAT(stats.gorc)},
@@ -69,27 +69,27 @@ static struct ixgbe_stats ixgbe_gstrings_stats[] = {
{"lsc_int", IXGBE_STAT(lsc_int)},
{"tx_busy", IXGBE_STAT(tx_busy)},
{"non_eop_descs", IXGBE_STAT(non_eop_descs)},
- {"rx_errors", IXGBE_NETDEV_STAT(stats.rx_errors)},
- {"tx_errors", IXGBE_NETDEV_STAT(stats.tx_errors)},
- {"rx_dropped", IXGBE_NETDEV_STAT(stats.rx_dropped)},
- {"tx_dropped", IXGBE_NETDEV_STAT(stats.tx_dropped)},
- {"multicast", IXGBE_NETDEV_STAT(stats.multicast)},
+ {"rx_errors", IXGBE_NETDEV_STAT(rx_errors)},
+ {"tx_errors", IXGBE_NETDEV_STAT(tx_errors)},
+ {"rx_dropped", IXGBE_NETDEV_STAT(rx_dropped)},
+ {"tx_dropped", IXGBE_NETDEV_STAT(tx_dropped)},
+ {"multicast", IXGBE_NETDEV_STAT(multicast)},
{"broadcast", IXGBE_STAT(stats.bprc)},
{"rx_no_buffer_count", IXGBE_STAT(stats.rnbc[0]) },
- {"collisions", IXGBE_NETDEV_STAT(stats.collisions)},
- {"rx_over_errors", IXGBE_NETDEV_STAT(stats.rx_over_errors)},
- {"rx_crc_errors", IXGBE_NETDEV_STAT(stats.rx_crc_errors)},
- {"rx_frame_errors", IXGBE_NETDEV_STAT(stats.rx_frame_errors)},
+ {"collisions", IXGBE_NETDEV_STAT(collisions)},
+ {"rx_over_errors", IXGBE_NETDEV_STAT(rx_over_errors)},
+ {"rx_crc_errors", IXGBE_NETDEV_STAT(rx_crc_errors)},
+ {"rx_frame_errors", IXGBE_NETDEV_STAT(rx_frame_errors)},
{"hw_rsc_aggregated", IXGBE_STAT(rsc_total_count)},
{"hw_rsc_flushed", IXGBE_STAT(rsc_total_flush)},
{"fdir_match", IXGBE_STAT(stats.fdirmatch)},
{"fdir_miss", IXGBE_STAT(stats.fdirmiss)},
- {"rx_fifo_errors", IXGBE_NETDEV_STAT(stats.rx_fifo_errors)},
- {"rx_missed_errors", IXGBE_NETDEV_STAT(stats.rx_missed_errors)},
- {"tx_aborted_errors", IXGBE_NETDEV_STAT(stats.tx_aborted_errors)},
- {"tx_carrier_errors", IXGBE_NETDEV_STAT(stats.tx_carrier_errors)},
- {"tx_fifo_errors", IXGBE_NETDEV_STAT(stats.tx_fifo_errors)},
- {"tx_heartbeat_errors", IXGBE_NETDEV_STAT(stats.tx_heartbeat_errors)},
+ {"rx_fifo_errors", IXGBE_NETDEV_STAT(rx_fifo_errors)},
+ {"rx_missed_errors", IXGBE_NETDEV_STAT(rx_missed_errors)},
+ {"tx_aborted_errors", IXGBE_NETDEV_STAT(tx_aborted_errors)},
+ {"tx_carrier_errors", IXGBE_NETDEV_STAT(tx_carrier_errors)},
+ {"tx_fifo_errors", IXGBE_NETDEV_STAT(tx_fifo_errors)},
+ {"tx_heartbeat_errors", IXGBE_NETDEV_STAT(tx_heartbeat_errors)},
{"tx_timeout_count", IXGBE_STAT(tx_timeout_count)},
{"tx_restart_queue", IXGBE_STAT(restart_queue)},
{"rx_long_length_errors", IXGBE_STAT(stats.roc)},
^ permalink raw reply related
* Re: Very low latency TCP for clusters
From: Rick Jones @ 2010-07-20 17:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, netdev
In-Reply-To: <1279603570.2458.66.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le lundi 19 juillet 2010 à 16:37 -0700, Tom Herbert a écrit :
>
>>That's pretty pokey ;-) I see numbers around 25 usecs between to
>>machines, this is with TCP_NBRR. With TCP_RR it's more like 35 usecs,
>>so eliminating the scheduler is already a big reduction. That leaves
>>18 usecs in device time, interrupt processing, network, and cache
>>misses; 7 usecs in TCP processing, user space. While 5 usecs is an
>>aggressive goal, I am not ready to concede that there's an
>>architectural limit in either NICs, TCP, or sockets that can't be
>>overcome.
>
> Last time I tried TCP_NBRR, it was not working (not even compiled in), I
> guess I should submit a bug report to Rick ;)
Indeed!-) Actually, my first thought upon reading what Tom wrote was "Wow, I'm
amazed it still works" :) That code probably hasn't been visited much since the
heydays of T/TCP (transactional).
Getting it compiled-in probably required a hand-editing of the config.h file
after the ./configure. Patches to add a --enable-nbrr would be graciously accepted.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: Question about way that NICs deliver packets to the kernel
From: Rick Jones @ 2010-07-20 17:16 UTC (permalink / raw)
To: Junchang Wang; +Cc: Ben Hutchings, romieu, netdev
In-Reply-To: <20100720011522.GA4123@host-a-160.ustcsz.edu.cn>
Junchang Wang wrote:
> On Fri, Jul 16, 2010 at 10:58:46AM -0700, Rick Jones wrote:
>
>>>Hi Ben,
>>>I added options -c -C to netperf's command line. Result is as follows:
>>> scheme 1 scheme 2 Imp.
>>>Throughput: 683M 718M 5%
>>>CPU usage: 47.8% 45.6%
>>>
>>>That really surprised me because "top" command showed the CPU usage
>>>was fluctuating between 0.5% and 1.5% rather that between 45% and 50%.
>>
>
> Hi rick,
> very sorry for my late reply. Just recovered from the final exam.:)
>
>
>>Can you tell us a bit more about the system, and which version of
>>netperf you are using?
>
>
> The target machine is a Pentium Dual-core E2200 desktop with a r8169
> gigabit NIC. (I couldn't find a better server with old pci slot.)
>
> Another machine is a Nehalem based system with Intel 82576 NIC.
>
> The target machine executes netserver and Nehalem machine executes netperf.
> The version of netperf is 2.4.5
>
>
>>Any chance that the CPU utilization you were
>>looking at in top was just that being charged to netperf the process?
>
>
> What I see on target machine is as follows:
>
> top - 21:37:12 up 21 min, 6 users, load average: 0.43, 0.28, 0.19
> Tasks: 152 total, 2 running, 149 sleeping, 0 stopped, 1 zombie
> Cpu(s): 2.3%us, 1.5%sy, 0.1%ni, 89.5%id, 2.7%wa, 0.0%hi, 3.9%si, 0.0%
> Mem: 2074064k total, 690200k used, 1383864k free, 39372k buffers
> Swap: 2096476k total, 0k used, 2096476k free, 435044k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 3916 root 20 0 2228 584 296 R 84.6 0.0 0:07.12 netserver
You said this was a dual-core system right? So two cores, no threads? If so,
then that does look odd - if netserver is consuming 84% of a CPU (core) and
there are only two CPUs (cores) in the system, how the system can be 89.5% idle
is beyond me. The 48% reported by netperf below makes better sense. If you press
"1" while top is running it should start to show per-CPU statistics
> It shows the CPU usage of taget machine is around 10%.
>
> while Nehalem machine's report is as follows:
>
> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.1 (192.168.2.1) port 0 AF_INET
> Recv Send Send Utilization Service Demand
> Socket Socket Message Elapsed Send Recv Send Recv
> Size Size Size Time Throughput local remote local remote
> bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
>
> 87380 16384 16384 10.05 679.79 1.63 48.27 1.571 11.634
>
> It shows the CPU usage of target machine is 48.27%.
Clearly something is out of joint - let's go off-list (or on to
netperf-talk@netperf.org) and hash that out to see what may be happening. It
will probably involve variations on grabbing the top-of-trunk, adding the debug
option etc.
>
>
>>"Network processing" does not often get charged to the responsible
>>process, so netperf reports system-wide CPU utilization on the
>>assumption it is the only thing causing the CPUs to be utilized.
>
>
> My understand of your commends is:
> 1)except running in ksoftirqd, network processing cannot be correctly counted
> because it runs in interrupt contexts that do not get charged to a correct
> process. So "top" misses lots of CPU usage in high interrupt rate network
> situation.
Top *shouldn't* miss it as far as reporting overall CPU utlization. It just may
not be charged to the process on who's behalf the work is done.
> 2)As you have mentioned in netperf's manual, netperf uses /proc/stat on Linux
> to retrieve time spent in idle mode. In other words, it accumulates cpu time
> spent in all other modes, including hardware interrupt, software interrupt,
> etc., making the CPU usage more accurate in high interrupt situation.
That is the theory. In practice however... while the top output you've
provided looks like there is an "issue" in top, netperf has been known to have a
bug or three.
> 3)Since most processes in target machine are in sleeping mode, the CPU usage
> of network processing is in actually very close to 48.27%. Right?
I do not expect there to be a huge discrepancy between the overall CPU
utilization reported by top and the CPU utilization reported by netperf. That
there seems to be such a discrepancy has me wanting to make certain that netperf
is operating correctly.
happy benchmarking,
rick jones
>
> Correct me if any of them are incorrect. Thanks.
>
> --Junchang
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: Add batman-adv meshing protocol
From: Sven Eckelmann @ 2010-07-20 17:16 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
siwu-MaAgPAbsBIVS8oHt8HbXEIQuADTiUCJX
In-Reply-To: <20100720.095928.113690788.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 1169 bytes --]
On Tuesday 20 July 2010 18:59:28 David Miller wrote:
> From: Sven Eckelmann <sven.eckelmann-Mmb7MZpHnFY@public.gmane.org>
> Date: Tue, 20 Jul 2010 10:28:10 +0200
>
> > I would leave that to the original author of those functions.
>
> Whoever you leave it to, this needs to be fixed up before this
> code can be integrated. So if those people are not active or
> don't have time, you very much should consider the reality that
> you might have to do these fixups yourself.
They are active and informed about it. I never wanted that you integrate it
right away, but asked for a review to get everything in shape for the real
move from staging to net.
Maybe there is a misunderstanding who I am. When you look at the MAINTAINERS
file than you will notice that my name doesn't appear. I just volunteered to
keep the different branches in sync and submitted it for a review to you and
netdev after a discussion with Marek Lindner. He is together with Simon
Wunderlich the real maintainer of the codebase.
I will stop here if you prefer not to talk with an intermediary. So Marek or
Simon have to work directly with you.
thanks,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e1000: allow option to limit number of descriptors down to 48 per ring
From: Brandeburg, Jesse @ 2010-07-20 17:12 UTC (permalink / raw)
To: Eric Dumazet
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, bphilips@novell.com, Duyck, Alexander H
In-Reply-To: <1279600823.2458.59.camel@edumazet-laptop>
On Mon, 19 Jul 2010, Eric Dumazet wrote:
> Le lundi 19 juillet 2010 à 16:43 -0700, Jeff Kirsher a écrit :
> > From: Alexander Duyck <alexander.h.duyck@intel.com>
> >
> > This change makes it possible to limit the number of descriptors down to 48
> > per ring. The reason for this change is to address a variation on hardware
> > errata 10 for 82546GB in which descriptors will be lost if more than 32
> > descriptors are fetched and the PCI-X MRBC is 512.
> > -#define E1000_MIN_TXD 80
> > +#define E1000_MIN_TXD 48
> > #define E1000_MAX_82544_TXD 4096
> >
> > #define E1000_DEFAULT_RXD 256
> > #define E1000_MAX_RXD 256
> > -#define E1000_MIN_RXD 80
> > +#define E1000_MIN_RXD 48
> > #define E1000_MAX_82544_RXD 4096
> So this limit is a pure software one ?
Yes, the hardware will work fine (with the exception of some limits when
certain performance registers are configured like [TR]XDCTL) all the way
down to 1 descriptor, that said, the practical limit is probably more like
8 for RX descriptors, and is 2 * (MAX_SKB_FRAGS + 1) for transmit if TSO
is enabled.
if all offloads are disabled you could run with only 8 tx descriptors, and
I believe it would work fine.
> Why not let an admin chose a lower limit if he wants to ?
I think in this case just to prevent odd interaction bugs with low values
(there would have to be several driver changes and the testing work would
increase to support very low values)
> I am asking because big ring sizes can be a latency source in some
> workloads.
yes, if you are trying to pace traffic in software. That said, at least
on transmit, most frames exit immediately from the hardware unless some
external event like flow control is slowing down transmit.
Jesse
^ permalink raw reply
* Re: [PATCH] net: Add batman-adv meshing protocol
From: David Miller @ 2010-07-20 16:59 UTC (permalink / raw)
To: sven.eckelmann; +Cc: b.a.t.m.a.n, siwu, netdev
In-Reply-To: <201007201028.12470.sven.eckelmann@gmx.de>
From: Sven Eckelmann <sven.eckelmann@gmx.de>
Date: Tue, 20 Jul 2010 10:28:10 +0200
> I would leave that to the original author of those functions.
Whoever you leave it to, this needs to be fixed up before this
code can be integrated. So if those people are not active or
don't have time, you very much should consider the reality that
you might have to do these fixups yourself.
^ permalink raw reply
* [PATCH] drop_monitor: convert some kfree_skb call sites to consume_skb
From: Neil Horman @ 2010-07-20 16:45 UTC (permalink / raw)
To: netdev; +Cc: davem, viro, eparis, nhorman
Convert a few calls from kfree_skb to consume_skb
Noticed while I was working on dropwatch that I was detecting lots of internal
skb drops in several places. While some are legitimate, several were not,
freeing skbs that were at the end of their life, rather than being discarded due
to an error. This patch converts those calls sites from using kfree_skb to
consume_skb, which quiets the in-kernel drop_monitor code from detecting them as
drops. Tested successfully by myself
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Eric Paris <eparis@redhat.com>
CC: Al Viro <viro@zeniv.linux.org.uk>
kernel/audit.c | 2 +-
net/netlink/af_netlink.c | 9 +++++----
net/unix/af_unix.c | 2 +-
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index c71bd26..8296aa5 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -407,7 +407,7 @@ static void kauditd_send_skb(struct sk_buff *skb)
audit_hold_skb(skb);
} else
/* drop the extra reference if sent ok */
- kfree_skb(skb);
+ consume_skb(skb);
}
static int kauditd_thread(void *dummy)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 7aeaa83..8648a99 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1076,14 +1076,15 @@ int netlink_broadcast_filtered(struct sock *ssk, struct sk_buff *skb, u32 pid,
sk_for_each_bound(sk, node, &nl_table[ssk->sk_protocol].mc_list)
do_one_broadcast(sk, &info);
- kfree_skb(skb);
+ consume_skb(skb);
netlink_unlock_table();
- kfree_skb(info.skb2);
-
- if (info.delivery_failure)
+ if (info.delivery_failure) {
+ kfree_skb(info.skb2);
return -ENOBUFS;
+ } else
+ consume_skb(info.skb2);
if (info.delivered) {
if (info.congested && (allocation & __GFP_WAIT))
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 75ba48b..4414a18 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1906,7 +1906,7 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
break;
}
- kfree_skb(skb);
+ consume_skb(skb);
if (siocb->scm->fp)
break;
^ permalink raw reply related
* Re: [net-next-2.6 PATCH 2/5] ixgbe: drop support for UDP in RSS hash generation
From: Eric Dumazet @ 2010-07-20 16:39 UTC (permalink / raw)
To: Alexander Duyck
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, bphilips@novell.com, Skidmore, Donald C
In-Reply-To: <4C45CAC6.1050006@intel.com>
Le mardi 20 juillet 2010 à 09:11 -0700, Alexander Duyck a écrit :
> The packets will still be hashed on source and destination IPv4/IPv6
> addresses. The change just drops reading the UDP source/destination
> ports since in the case of fragmented packets they are not available and
> as such were being parsed as IPv4/IPv6 packets. By making this change
> the queue selection is consistent between all packets in the UDP stream.
>
Excellent, this is perfect IMHO.
> The only regression I would expect to see would be in testing between
> two fixed systems since the IP addresses of the two systems would be
> fixed and so running multiple flows between the two would yield the same
> RSS hash for multiple UDP streams. As long as multiple ip addresses
> are used you should see multiple RSS hashes generated and as such the
> load should still be distributed.
>
Ack. Fortunately, one can still use RPS to spread load onto multiple
cpus in this case.
This until ixgpe fills skb->rxhash with a non null value.
If it happens one day, we shall remind _not_ filling it for UDP packets.
BTW, this reminds me a netdev discussion we had for bnx2x
http://www.kerneltrap.com/mailarchive/linux-netdev/2010/4/23/6275415/thread
And now, I understand why Toepliz hash doesnt use src port/dst port,
since this is not available on fragments, obviously...
Thanks !
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/5] ixgbe: drop support for UDP in RSS hash generation
From: Alexander Duyck @ 2010-07-20 16:11 UTC (permalink / raw)
To: Eric Dumazet
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, bphilips@novell.com, Skidmore, Donald C
In-Reply-To: <1279607980.2458.82.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le lundi 19 juillet 2010 à 16:59 -0700, Jeff Kirsher a écrit :
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> This change removes UDP from the supported protocols for RSS hashing. The
>> reason for removing this protocol is because IP fragmentation was causing a
>> network flow to be broken into two streams, one for fragmented, and one for
>> non-fragmented and this in turn was causing out-of-order issues.
>>
>
> Jeff, does it mean all UDP packets are going to be delivered to a single
> queue ?
>
> This would be a serious regression.
>
> Many UDP applications try hard to not use fragments.
>
> They are going to pay the price because some application :
> - Use big segments, fragmented.
> - Is subject to OOO artifacts.
>
> We would like some clarifications please :)
>
>
>
The packets will still be hashed on source and destination IPv4/IPv6
addresses. The change just drops reading the UDP source/destination
ports since in the case of fragmented packets they are not available and
as such were being parsed as IPv4/IPv6 packets. By making this change
the queue selection is consistent between all packets in the UDP stream.
The only regression I would expect to see would be in testing between
two fixed systems since the IP addresses of the two systems would be
fixed and so running multiple flows between the two would yield the same
RSS hash for multiple UDP streams. As long as multiple ip addresses
are used you should see multiple RSS hashes generated and as such the
load should still be distributed.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH net-next] drivers/acpi/acpica/utmisc.c: Use printk extension %pV
From: Bjorn Helgaas @ 2010-07-20 16:08 UTC (permalink / raw)
To: Joe Perches; +Cc: Len Brown, linux-acpi, linux-kernel, netdev, David Miller
In-Reply-To: <1279602367.19374.20.camel@Joe-Laptop.home>
On Monday, July 19, 2010 11:06:07 pm Joe Perches wrote:
> Consolidates the printk messages to a single
> call so the messages can not be interleaved.
>
> Reduces text a bit.
>
> $ size drivers/acpi/acpica/utmisc.o.*
> text data bss dec hex filename
> 7822 56 1832 9710 25ee drivers/acpi/acpica/utmisc.o.old
> 7748 56 1736 9540 2544 drivers/acpi/acpica/utmisc.o.new
>
> Depends on net-next commit 7db6f5fb65a82af03229eef104dc9899c5eecf33
> (vsprintf: Recursive vsnprintf: Add "%pV", struct va_format)
drivers/acpi/acpica/utmisc.c is part of the ACPI CA and is used in
several different OSes, but %pV sounds like a Linux-specific feature,
so I don't see how this patch can work.
Bjorn
^ permalink raw reply
* [PATCH net-next 3/3] cxgb4vf: add maintainer entry for cxgb4vf
From: Casey Leedom @ 2010-07-20 15:59 UTC (permalink / raw)
To: netdev
>From 7710873beb494b46333fdf9841b4a117bdb66a5a Mon Sep 17 00:00:00 2001
From: Casey Leedom <leedom@chelsio.com>
Date: Mon, 19 Jul 2010 17:55:33 -0700
Subject: [PATCH net-next 3/3] cxgb4vf: add maintainer entry for cxgb4vf
Adding myself as the official maintainer of the Chelsio T4 Virtual function
Driver (cxgb4vf).
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
MAINTAINERS | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c05b499..aa73c9a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1767,6 +1767,13 @@ W: http://www.openfabrics.org
S: Supported
F: drivers/infiniband/hw/cxgb4/
+CXGB4VF ETHERNET DRIVER (CXGB4VF)
+M: Casey Leedom <leedom@chelsio.com>
+L: netdev@vger.kernel.org
+W: http://www.chelsio.com
+S: Supported
+F: drivers/net/cxgb4vf/
+
CYBERPRO FB DRIVER
M: Russell King <linux@arm.linux.org.uk>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next 2/3] cxgb4vf: Fix bug where we were only allocating one queue in MSI mode
From: Casey Leedom @ 2010-07-20 15:59 UTC (permalink / raw)
To: netdev
>From 7e141cafe989958267803791aa1bcacfffe5cfb2 Mon Sep 17 00:00:00 2001
From: Casey Leedom <leedom@chelsio.com>
Date: Mon, 19 Jul 2010 17:53:48 -0700
Subject: [PATCH net-next 2/3] cxgb4vf: Fix bug where we were only allocating one queue in MSI mode
Fix bug in setup_sge_queues() where we were incorrectly only allocating a
single "Queue Set" for MSI mode.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index d065516..a165632 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -533,10 +533,9 @@ static int setup_sge_queues(struct adapter *adapter)
struct port_info *pi = netdev_priv(dev);
struct sge_eth_rxq *rxq = &s->ethrxq[pi->first_qset];
struct sge_eth_txq *txq = &s->ethtxq[pi->first_qset];
- int nqsets = (adapter->flags & USING_MSIX) ? pi->nqsets : 1;
int qs;
- for (qs = 0; qs < nqsets; qs++, rxq++, txq++) {
+ for (qs = 0; qs < pi->nqsets; qs++, rxq++, txq++) {
err = t4vf_sge_alloc_rxq(adapter, &rxq->rspq, false,
dev, msix++,
&rxq->fl, t4vf_ethrx_handler);
@@ -565,10 +564,9 @@ static int setup_sge_queues(struct adapter *adapter)
struct port_info *pi = netdev_priv(dev);
struct sge_eth_rxq *rxq = &s->ethrxq[pi->first_qset];
struct sge_eth_txq *txq = &s->ethtxq[pi->first_qset];
- int nqsets = (adapter->flags & USING_MSIX) ? pi->nqsets : 1;
int qs;
- for (qs = 0; qs < nqsets; qs++, rxq++, txq++) {
+ for (qs = 0; qs < pi->nqsets; qs++, rxq++, txq++) {
IQ_MAP(s, rxq->rspq.abs_id) = &rxq->rspq;
EQ_MAP(s, txq->q.abs_id) = &txq->q;
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next 1/3] cxgb4vf: Fix off-by-one error checking for the end of the mailbox delay array
From: Casey Leedom @ 2010-07-20 15:58 UTC (permalink / raw)
To: netdev
>From 1d32860335fad8c67e23254aec7c30750276f2b4 Mon Sep 17 00:00:00 2001
From: Casey Leedom <leedom@chelsio.com>
Date: Mon, 19 Jul 2010 17:51:46 -0700
Subject: [PATCH net-next 1/3] cxgb4vf: Fix off-by-one error checking for the end of the mailbox delay array
Fix off-by-one error in checking for the end of the mailbox response delay
array. We ended up walking off the end and, if we were unlucky, we'd end up
pulling in a 0 and never terminate the mailbox response delay loop ...
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/t4vf_hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb4vf/t4vf_hw.c b/drivers/net/cxgb4vf/t4vf_hw.c
index 1ef2528..ea1c123 100644
--- a/drivers/net/cxgb4vf/t4vf_hw.c
+++ b/drivers/net/cxgb4vf/t4vf_hw.c
@@ -163,7 +163,7 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void *cmd, int size,
for (i = 0; i < 500; i += ms) {
if (sleep_ok) {
ms = delay[delay_idx];
- if (delay_idx < ARRAY_SIZE(delay))
+ if (delay_idx < ARRAY_SIZE(delay) - 1)
delay_idx++;
msleep(ms);
} else
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net-next 0/3] cxgb4vf: fixes for several small issues discovered by QA
From: Casey Leedom @ 2010-07-20 15:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100719.204002.219738044.davem@davemloft.net>
| From: David Miller <davem@davemloft.net>
| Date: Monday, July 19, 2010 08:40 pm
|
| From: Casey Leedom <leedom@chelsio.com>
| Date: Mon, 19 Jul 2010 18:12:10 -0700
|
| > A couple of small (but important) fixes discovered by our QA people.
| > I've also
| >
| > included a patch to add myself as the maintainer of cxgb4vf in the
| > MAINTAINERS file which I think is the protocol but please correct me if
| > changes to that file are usually performed by someone else.
|
| Well, where are they?
Oops! Sorry!! It was my first effort at using "git send-email" and in my manic
attempt to make sure I wasn't screwing it up I had directed the patches to
myself to verify that the process worked and then forgot to change the To:
address to netdev@vger.kernel.org in my "real attempt."
Patches coming forthwith.
Casey
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox