* [PATCH] iproute2: ip: add wilcard support for device matching
From: Octavian Purdila @ 2010-12-10 14:58 UTC (permalink / raw)
To: netdev; +Cc: Lucian Adrian Grijincu, Vlad Dogaru, Octavian Purdila
Allow the users to specify a wildcard when selecting a device:
$ ip set link dev dummy* up
We do this by expanding the original command line in multiple lines
which we then feed via a pipe to a forked ip processed run in batch
mode.
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
---
ip/ip.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/ip/ip.c b/ip/ip.c
index b127d57..2e26488 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -18,6 +18,8 @@
#include <netinet/in.h>
#include <string.h>
#include <errno.h>
+#include <sys/types.h>
+#include <sys/wait.h>
#include "SNAPSHOT.h"
#include "utils.h"
@@ -139,10 +141,72 @@ static int batch(const char *name)
return ret;
}
+int main(int argc, char **argv);
+
+int expand_dev_pattern(int argc, char **argv, int pos)
+{
+ FILE *proc;
+ size_t n, dev_no;
+ char scanf_pattern[64], *line = NULL, *dev_base = argv[pos];
+ int p[2], i;
+ pid_t pid;
+
+ *strchr(dev_base, '*') = 0;
+ snprintf(scanf_pattern, sizeof(scanf_pattern), " %s%%d:", dev_base);
+
+ if (pipe(p) < 0) {
+ fprintf(stderr, "pipe() failed: %s\n", strerror(errno));
+ return -1;
+ }
+
+ pid = fork();
+ switch (pid) {
+ case -1:
+ fprintf(stderr, "fork failed: %s\n", strerror(errno));
+ return -1;
+ case 0:
+ {
+ char *nargv[] = { argv[0], "-b", "-" };
+ int ret;
+
+ dup2(p[0], 0); close(p[0]); close(p[1]);
+ ret = main(3, nargv);
+ exit(ret);
+ }
+ default:
+ dup2(p[1], 1); close(p[0]); close(p[1]);
+ }
+
+ proc = fopen("/proc/net/dev", "r");
+ if (!proc) {
+ fprintf(stderr, "can't open /proc/net/dev\n");
+ return -1;
+ }
+
+ while (getline(&line, &n, proc) > 0) {
+ if (sscanf(line, scanf_pattern, &dev_no) == 1) {
+ for (i = 1; i < argc; i++)
+ if (i != pos)
+ printf("%s ", argv[i]);
+ else
+ printf("%s%d ", dev_base, dev_no);
+ printf("\n");
+ }
+ }
+ free(line);
+
+ fflush(stdout); close(1);
+
+ waitpid(pid, NULL, 0);
+
+ return 0;
+}
int main(int argc, char **argv)
{
char *basename;
+ int i = 0;
+
basename = strrchr(argv[0], '/');
if (basename == NULL)
@@ -150,6 +214,12 @@ int main(int argc, char **argv)
else
basename++;
+ for (i = 1; i < argc - 1; i++) {
+ if (matches(argv[i], "dev") == 0 && strchr(argv[i+1], '*')) {
+ return expand_dev_pattern(argc, argv, i+1);
+ }
+ }
+
while (argc > 1) {
char *opt = argv[1];
if (strcmp(opt,"--") == 0) {
--
1.7.1
^ permalink raw reply related
* [PATCH] iproute2: add dynamic index and name hashes
From: Octavian Purdila @ 2010-12-10 14:59 UTC (permalink / raw)
To: netdev; +Cc: Lucian Adrian Grijincu, Vlad Dogaru, Octavian Purdila
The hashes sizes start with 16 entries and grow up to 2^20
entries. The hashes double when the entries in the LL map is greater
then the hash size.
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
---
lib/ll_map.c | 125 +++++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 103 insertions(+), 22 deletions(-)
diff --git a/lib/ll_map.c b/lib/ll_map.c
index b8b49aa..9831322 100644
--- a/lib/ll_map.c
+++ b/lib/ll_map.c
@@ -26,7 +26,8 @@ extern unsigned int if_nametoindex (const char *);
struct idxmap
{
- struct idxmap * next;
+ struct idxmap *idx_next;
+ struct idxmap *name_next;
unsigned index;
int type;
int alen;
@@ -35,31 +36,100 @@ struct idxmap
char name[16];
};
-static struct idxmap *idxmap[16];
+struct idxmap_head {
+ struct idxmap *next;
+};
+
+static int hbits = 4, entries;
+static struct idxmap_head *idx_hash, *name_hash;
+
+static unsigned int name_hashfn(const char *name)
+{
+ const unsigned char *c = (const unsigned char *)name;
+ unsigned int hash = 0;
+
+ while (*c)
+ hash = 31*hash + *c++;
+
+ return hash;
+}
+
+static inline unsigned int htrunc(unsigned int value, int bits)
+{
+ return value % (1<<bits);
+}
+
+void grow_hashes(void)
+{
+ struct idxmap_head *new_idx_hash, *new_name_hash;
+ struct idxmap *next, *im;
+ int hidx, hname, i, new_size = 1<<(hbits+1);
+
+ if (hbits == 20)
+ return;
+
+ new_idx_hash = malloc(new_size * sizeof(struct idxmap_head));
+ new_name_hash = malloc(new_size * sizeof(struct idxmap_head));
+
+ if (!new_idx_hash || !new_name_hash)
+ return;
+
+ for (i = 0; i < (hbits<<1); i++)
+ for (im = idx_hash[i].next;
+ im != NULL && (next = im->idx_next, 1); im = next) {
+ hidx = htrunc(im->index, hbits + 1);
+ im->idx_next = new_idx_hash[hidx].next;
+ new_idx_hash[hidx].next = im;
+
+ hname = htrunc(name_hashfn(im->name), hbits + 1);
+ im->name_next = new_name_hash[hname].next;
+ new_name_hash[hname].next = im;
+ }
+
+ free(idx_hash);
+ idx_hash = new_idx_hash;
+
+ free(name_hash);
+ name_hash = new_name_hash;
+
+ hbits = hbits + 1;
+}
int ll_remember_index(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg)
{
- int h;
+ int hidx, hname;
struct ifinfomsg *ifi = NLMSG_DATA(n);
- struct idxmap *im, **imp;
+ struct idxmap *im;
struct rtattr *tb[IFLA_MAX+1];
+ if (!idx_hash) {
+ idx_hash = malloc((1<<hbits) * sizeof(struct idxmap_head));
+ if (!idx_hash)
+ return -1;
+ }
+
+ if (!name_hash) {
+ name_hash = malloc((1<<hbits) * sizeof(struct idxmap_head));
+ if (!name_hash)
+ return -1;
+ }
+
if (n->nlmsg_type != RTM_NEWLINK)
return 0;
if (n->nlmsg_len < NLMSG_LENGTH(sizeof(ifi)))
return -1;
-
memset(tb, 0, sizeof(tb));
parse_rtattr(tb, IFLA_MAX, IFLA_RTA(ifi), IFLA_PAYLOAD(n));
if (tb[IFLA_IFNAME] == NULL)
return 0;
- h = ifi->ifi_index&0xF;
+ hidx = htrunc(ifi->ifi_index, hbits);
+ hname = htrunc(name_hashfn(RTA_DATA(tb[IFLA_IFNAME])), hbits);
- for (imp=&idxmap[h]; (im=*imp)!=NULL; imp = &im->next)
+ for (im = idx_hash[hidx].next; im != NULL; im = im->idx_next)
if (im->index == ifi->ifi_index)
break;
@@ -67,9 +137,15 @@ int ll_remember_index(const struct sockaddr_nl *who,
im = malloc(sizeof(*im));
if (im == NULL)
return 0;
- im->next = *imp;
+
+ entries++;
im->index = ifi->ifi_index;
- *imp = im;
+
+ im->idx_next = idx_hash[hidx].next;
+ idx_hash[hidx].next = im;
+
+ im->name_next = name_hash[hname].next;
+ name_hash[hname].next = im;
}
im->type = ifi->ifi_type;
@@ -85,6 +161,10 @@ int ll_remember_index(const struct sockaddr_nl *who,
memset(im->addr, 0, sizeof(im->addr));
}
strcpy(im->name, RTA_DATA(tb[IFLA_IFNAME]));
+
+ if (entries > (1<<hbits))
+ grow_hashes();
+
return 0;
}
@@ -94,7 +174,7 @@ const char *ll_idx_n2a(unsigned idx, char *buf)
if (idx == 0)
return "*";
- for (im = idxmap[idx&0xF]; im; im = im->next)
+ for (im = idx_hash[htrunc(idx, hbits)].next; im; im = im->idx_next)
if (im->index == idx)
return im->name;
snprintf(buf, 16, "if%d", idx);
@@ -115,7 +195,7 @@ int ll_index_to_type(unsigned idx)
if (idx == 0)
return -1;
- for (im = idxmap[idx&0xF]; im; im = im->next)
+ for (im = idx_hash[htrunc(idx, hbits)].next; im; im = im->idx_next)
if (im->index == idx)
return im->type;
return -1;
@@ -128,7 +208,7 @@ unsigned ll_index_to_flags(unsigned idx)
if (idx == 0)
return 0;
- for (im = idxmap[idx&0xF]; im; im = im->next)
+ for (im = idx_hash[htrunc(idx, hbits)].next; im; im = im->idx_next)
if (im->index == idx)
return im->flags;
return 0;
@@ -142,7 +222,7 @@ unsigned ll_index_to_addr(unsigned idx, unsigned char *addr,
if (idx == 0)
return 0;
- for (im = idxmap[idx&0xF]; im; im = im->next) {
+ for (im = idx_hash[htrunc(idx, hbits)].next; im; im = im->idx_next) {
if (im->index == idx) {
if (alen > sizeof(im->addr))
alen = sizeof(im->addr);
@@ -155,25 +235,26 @@ unsigned ll_index_to_addr(unsigned idx, unsigned char *addr,
return 0;
}
+
unsigned ll_name_to_index(const char *name)
{
static char ncache[16];
static int icache;
struct idxmap *im;
- int i;
+ int hname;
unsigned idx;
if (name == NULL)
return 0;
if (icache && strcmp(name, ncache) == 0)
return icache;
- for (i=0; i<16; i++) {
- for (im = idxmap[i]; im; im = im->next) {
- if (strcmp(im->name, name) == 0) {
- icache = im->index;
- strcpy(ncache, name);
- return im->index;
- }
+
+ hname = htrunc(name_hashfn(name), hbits);
+ for (im = name_hash[hname].next; im; im = im->name_next) {
+ if (strcmp(im->name, name) == 0) {
+ icache = im->index;
+ strcpy(ncache, name);
+ return im->index;
}
}
@@ -190,7 +271,7 @@ int ll_init_map(struct rtnl_handle *rth)
exit(1);
}
- if (rtnl_dump_filter(rth, ll_remember_index, &idxmap, NULL, NULL) < 0) {
+ if (rtnl_dump_filter(rth, ll_remember_index, NULL, NULL, NULL) < 0) {
fprintf(stderr, "Dump terminated\n");
exit(1);
}
--
1.7.1
^ permalink raw reply related
* [PATCH] iproute2: initialize the ll_map only once
From: Octavian Purdila @ 2010-12-10 14:59 UTC (permalink / raw)
To: netdev; +Cc: Lucian Adrian Grijincu, Vlad Dogaru, Octavian Purdila
Avoid initializing the LL map (which involves a costly RTNL dump)
multiple times. This can happen when running in batch mode.
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
---
lib/ll_map.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/lib/ll_map.c b/lib/ll_map.c
index 9831322..9c6144a 100644
--- a/lib/ll_map.c
+++ b/lib/ll_map.c
@@ -266,6 +266,11 @@ unsigned ll_name_to_index(const char *name)
int ll_init_map(struct rtnl_handle *rth)
{
+ static int initialized;
+
+ if (initialized)
+ return 0;
+
if (rtnl_wilddump_request(rth, AF_UNSPEC, RTM_GETLINK) < 0) {
perror("Cannot send dump request");
exit(1);
@@ -275,5 +280,8 @@ int ll_init_map(struct rtnl_handle *rth)
fprintf(stderr, "Dump terminated\n");
exit(1);
}
+
+ initialized = 1;
+
return 0;
}
--
1.7.1
^ permalink raw reply related
* Workqueues vs. kernel threads for processing asynchronous socket events
From: Martin Lucina @ 2010-12-10 15:27 UTC (permalink / raw)
To: netdev; +Cc: Martin Sustrik
Hi,
I'm trying to find the best mechanism to process events from kernel space
sockets in an asynchronous manner. The work in progress code I have at the
moment tries to at least call kernel_accept() on a bound TCP socket when it
gets called by the underlying sk->sk_data_ready callback.
The current approach I have is to use a workqueue and try to schedule work
inside the callback, but this has the kernel complaining about "scheduling
while atomic", so it doesn't look like it's the right approach? Am I
allowed to call schedule_work() from the context of a sk->sk_data_ready
callback or not?
Sunrpc/knfsd appears to use a different approach where
svc_tcp_listen_data_ready() sets the appropriate state and then calls
wake_up_interruptible_all(sk_sleep(sk)) -- it's not clear who this is
waking up, the nfsd kernel thread or someone else?
Any advice on what is the best future-proof approach to use for this kind
of thing in a new project?
-mato
^ permalink raw reply
* Re: [net-next-2.6 03/27] Documentation/networking/igb.txt: update documentation
From: Ben Hutchings @ 2010-12-10 15:50 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, davem, netdev, gospo, bphilips
In-Reply-To: <1291974667-30254-4-git-send-email-jeffrey.t.kirsher@intel.com>
On Fri, 2010-12-10 at 01:50 -0800, Jeff Kirsher wrote:
> Update Intel Wired LAN igb documentation.
>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> Documentation/networking/igb.txt | 22 +++++++++++++++++++---
> 1 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt
> index ab2d718..393bdb7 100644
> --- a/Documentation/networking/igb.txt
> +++ b/Documentation/networking/igb.txt
> @@ -36,6 +36,7 @@ Default Value: 0
> This parameter adds support for SR-IOV. It causes the driver to spawn up to
> max_vfs worth of virtual function.
>
> +
> Additional Configurations
> =========================
>
> @@ -60,7 +61,8 @@ Additional Configurations
> Ethtool
> -------
> The driver utilizes the ethtool interface for driver configuration and
> - diagnostics, as well as displaying statistical information.
> + diagnostics, as well as displaying statistical information. The latest
> + version of Ethtool can be found at:
>
> http://sourceforge.net/projects/gkernel.
Please update this to:
http://ftp.kernel.org/pub/software/network/ethtool/
> @@ -103,8 +105,8 @@ Additional Configurations
>
> NOTE: You need to have inet_lro enabled via either the CONFIG_INET_LRO or
> CONFIG_INET_LRO_MODULE kernel config option. Additionally, if
> - CONFIG_INET_LRO_MODULE is used, the inet_lro module needs to be loaded
> - before the igb driver.
> + CONFIG_INET_LRO_MODULE is used, the inet_lro module needs to be loaded before
> + the igb driver.
This should be removed as you don't use inet_lro any more.
> You can verify that the driver is using LRO by looking at these counters in
> Ethtool:
> @@ -116,6 +118,20 @@ Additional Configurations
>
> NOTE: IPv6 and UDP are not supported by LRO.
>
> + MAC and VLAN anti-spoofing feature
> + ----------------------------------
> + When a malicious driver attempts to send a spoofed packet, it is dropped by
> + the hardware and not transmitted. An interrupt is sent to the PF driver
> + notifying it of the spoof attempt.
> +
> + When a spoofed packet is detected the PF driver will send the following
> + message to the system log (displayed by the "dmesg" command):
> +
> + Spoof event(s) detected on VF(n)
> +
> + Where n=the VF that attempted to do the spoofing.
I can't see that message in the PF driver code; does this actually apply
to the in-tree driver? Also I hope this is rate-limited.
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] [Bug 24472] Kernel panic - not syncing: Fatal Exception
From: Jarek Poplawski @ 2010-12-10 15:55 UTC (permalink / raw)
To: Andrej Ota
Cc: Paweł Staszewski, Andrew Morton, netdev, Paul Mackerras,
bugzilla-daemon, bugme-daemon, pstaszewski, Eric Dumazet,
David Miller
In-Reply-To: <4D023DE4.8000400@ota.si>
On Fri, Dec 10, 2010 at 03:49:08PM +0100, Andrej Ota wrote:
> Move kfree_skb which was causing memory corruption to new location, while still keeping appropriate return value for function __pppoe_xmit. Prevents memory corruption and consequent kernel panic when PPPoE peer terminates the link.
Andrej, a slight misunderstanding - probably I should be more explicit.
I sent this link, which explains why return shouldn't be zero:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=db7bf6d97c6956b7eb0f22131cb5c37bd41f33c0
So the simplest fix is to revert this one change only.
If you disagree with this let me know.
You should also fix the subject to something more meaningful, e.g.:
[PATCH] pppoe: Fix kernel panic caused by __pppoe_xmit
Please, break lines in the changelog around 70 lines and add it
fixes commit 55c95e738da85373965cb03b4f975d0fd559865b.
Thanks,
Jarek P.
>
> Signed-off-by: Andrej Ota [andrej@ota.si]
> Reported-by: Pawel Staszewski [pstaszewski@artcom.pl]
> ---
> drivers/net/pppoe.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
> index d72fb05..1a21dce 100644
> --- a/drivers/net/pppoe.c
> +++ b/drivers/net/pppoe.c
> @@ -924,8 +924,10 @@ static int __pppoe_xmit(struct sock *sk, struct sk_buff *skb)
> /* Copy the data if there is no space for the header or if it's
> * read-only.
> */
> - if (skb_cow_head(skb, sizeof(*ph) + dev->hard_header_len))
> + if (skb_cow_head(skb, sizeof(*ph) + dev->hard_header_len)) {
> + kfree_skb(skb);
> goto abort;
> + }
>
> __skb_push(skb, sizeof(*ph));
> skb_reset_network_header(skb);
> @@ -947,7 +949,6 @@ static int __pppoe_xmit(struct sock *sk, struct sk_buff *skb)
> return 1;
>
> abort:
> - kfree_skb(skb);
> return 0;
> }
>
> ---
>
> Andrej Ota.
^ permalink raw reply
* Re: Adding Support for SG,GSO,GRO
From: Michał Mirosław @ 2010-12-10 16:01 UTC (permalink / raw)
To: David Lamparter; +Cc: David Miller, bhutchings, srk, netdev, Jens Axboe
In-Reply-To: <20101210143140.GD3536057@jupiter.n2.diac24.net>
W dniu 10 grudnia 2010 15:31 użytkownik David Lamparter
<equinox@diac24.net> napisał:
> On Fri, Dec 10, 2010 at 03:18:11PM +0100, Michał Mirosław wrote:
>> I'm trying to understand the dependency because it looks artificial for me.
>
> You have the data you want to send in the RAM, somewhere, possibly
> scattered. The application calls sendfile(). The kernel puts the
> transmission in the network card's queue, which might already have lots
> of entries.
>
> A millisecond later - an eternity for the CPU - the card decides to do
> the transmission.
>
> However, the data might have changed in the meantime.
>
> sendfile() is defined so that it works asynchronously, that means if you
> change the data while it is in the queue, you get unpredictable results.
>
> But, what you should NOT get is packets with an invalid checksum.
> Whatever data you are sending, it needs to have a correct checksum.
>
> Now, if the card does the checksum itself, everything is fine. But what
> are you supposed to do if the card can't checksum? Call back the kernel
> at the point where the card does the TX? That's pointless (and racy).
> Pre-calculate the Checksum at submission time? Doesn't work, you would
> have to make a copy of the data, so it doesn't change anymore, so the
> checksum stays correct. But not copying the data is the whole point of
> sendfile().
The question is do we really want good checksum for bogus data? I
think that what matters is that good data (it had not changed between
queuing and sending, and so the checksum does not depend on whether
hardware or software calculated it) need to be accompanied by good
checksum. For broken data it would be even better to not send
anything, but that's not always possible. Bad checksum in this case is
actually a good thing as it clearly shows that something is broken in
the sender and avoids accepting the data as valid at the receiving
end.
sendfile() is supposed to replace read()/write() loops to avoid
copying data buffers. Whatever the optimizations, it has no additional
cavat that it might corrupt the transfer. Fixing the checksum in case
data gets corrupted is not the right thing, I think.
The change of file data might happen if sendfile() submits page from
pagecache when something writes to the file, or when an application
modifies vmsplice()-submitted memory. In current kernel sendfile() is
a wrapper around splice(), and so has a kernel pipe buffer between
file and the socket. Can this hide the possible data changes?
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] kptr_restrict for hiding kernel pointers from unprivileged users
From: Peter Zijlstra @ 2010-12-10 16:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dan Rosenberg, linux-kernel, linux-security-module, netdev
In-Reply-To: <1291865039.2795.46.camel@edumazet-laptop>
On Thu, 2010-12-09 at 04:23 +0100, Eric Dumazet wrote:
> > + if (kptr_restrict) {
> > + if (in_interrupt())
> > + WARN(1, "%%pK used in interrupt context.\n");
>
> So caller can not block BH ?
>
> This seems wrong to me, please consider :
>
> normal process context :
>
> spin_lock_bh() ...
>
> for (...)
> {xxx}printf( ... "%pK" ...)
>
> spin_unlock_bh();
That's a bug in in_interrupt(), one I've been pointing out for a long
while. Luckily we recently grew the infrastructure to deal with it.
If you write it as: if (in_irq() || in_serving_softirq() || in_nmi())
you'll not trigger for the above example.
Ideally in_serving_softirq() wouldn't exist and in_softirq() would do
what in_server_softirq() does -- which would make it symmetric with the
hardirq functions -- but nobody has found time to audit all in_softirq()
users.
^ permalink raw reply
* Re: [PATCH] iproute2: add dynamic index and name hashes
From: Daniel Baluta @ 2010-12-10 16:09 UTC (permalink / raw)
To: Octavian Purdila; +Cc: netdev, Lucian Adrian Grijincu, Vlad Dogaru
In-Reply-To: <1291993164-8793-1-git-send-email-opurdila@ixiacom.com>
> + if (!idx_hash) {
> + idx_hash = malloc((1<<hbits) * sizeof(struct idxmap_head));
> + if (!idx_hash)
> + return -1;
> + }
> +
> + if (!name_hash) {
> + name_hash = malloc((1<<hbits) * sizeof(struct idxmap_head));
> + if (!name_hash)
Can you reach this point with idx_hash non-null? Well, then avoid
memory leaks by freeing it.
> + return -1;
> + }
thanks,
Daniel.
^ permalink raw reply
* Re: [PATCH] Fix build system and configure script to use for cross build. Optional IPv6.
From: Stephen Hemminger @ 2010-12-10 16:14 UTC (permalink / raw)
To: Serj Kalichev; +Cc: netdev
In-Reply-To: <1291995271-9912-1-git-send-email-serj.kalichev@gmail.com>
On Fri, 10 Dec 2010 18:34:31 +0300
Serj Kalichev <serj.kalichev@gmail.com> wrote:
> The Makefiles and configure script understand the external variables like
> CC, CFLAGS, LDFLAGS etc. So it can be used for cross build easily. The
> configure script use CC instead hardcoded gcc and search for the xtables
> within specified SYSROOT but not on the host. Two checks were added. The
> check for the IPv6 support and check for the Berkeley DB availability.
> The iproute2 can be build without IPv6 now.
>
> Signed-off-by: Serj Kalichev <serj.kalichev@gmail.com>
IPv6 support should not be optional.
--
^ permalink raw reply
* Re: [PATCH] iproute2: ip: add wilcard support for device matching
From: Stephen Hemminger @ 2010-12-10 16:18 UTC (permalink / raw)
To: Octavian Purdila; +Cc: netdev, Lucian Adrian Grijincu, Vlad Dogaru
In-Reply-To: <1291993092-8675-1-git-send-email-opurdila@ixiacom.com>
On Fri, 10 Dec 2010 16:58:12 +0200
Octavian Purdila <opurdila@ixiacom.com> wrote:
> Allow the users to specify a wildcard when selecting a device:
>
> $ ip set link dev dummy* up
>
> We do this by expanding the original command line in multiple lines
> which we then feed via a pipe to a forked ip processed run in batch
> mode.
>
Seems like feature creep. Can't you do this with bash completion
script instead.
^ permalink raw reply
* Re: Adding Support for SG,GSO,GRO
From: Ben Hutchings @ 2010-12-10 16:20 UTC (permalink / raw)
To: Michał Mirosław
Cc: David Lamparter, David Miller, srk, netdev, Jens Axboe
In-Reply-To: <AANLkTi=cVufUAHn6LRs_vG-cW2cY87SdP9MOE7i5Ru09@mail.gmail.com>
On Fri, 2010-12-10 at 17:01 +0100, Michał Mirosław wrote:
[...]
> The question is do we really want good checksum for bogus data?
[...]
It's not bogus data. It's a snapshot of the file contents at some
arbitrary point in time.
Now please stop wasting your own time and that of the networking
maintainers, and remember to check for checksum offload next time you
need to select a network controller.
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] iproute2: add dynamic index and name hashes
From: Stephen Hemminger @ 2010-12-10 16:20 UTC (permalink / raw)
To: Octavian Purdila; +Cc: netdev, Lucian Adrian Grijincu, Vlad Dogaru
In-Reply-To: <1291993164-8793-1-git-send-email-opurdila@ixiacom.com>
On Fri, 10 Dec 2010 16:59:24 +0200
Octavian Purdila <opurdila@ixiacom.com> wrote:
> The hashes sizes start with 16 entries and grow up to 2^20
> entries. The hashes double when the entries in the LL map is greater
> then the hash size.
>
> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
> ---
> lib/ll_map.c | 125 +++++++++++++++++++++++++++++++++++++++++++++++----------
> 1 files changed, 103 insertions(+), 22 deletions(-)
>
> diff --git a/lib/ll_map.c b/lib/ll_map.c
> index b8b49aa..9831322 100644
> --- a/lib/ll_map.c
> +++ b/lib/ll_map.c
> @@ -26,7 +26,8 @@ extern unsigned int if_nametoindex (const char *);
>
> struct idxmap
> {
> - struct idxmap * next;
> + struct idxmap *idx_next;
> + struct idxmap *name_next;
> unsigned index;
> int type;
> int alen;
> @@ -35,31 +36,100 @@ struct idxmap
> char name[16];
> };
>
> -static struct idxmap *idxmap[16];
This is user space, and memory space is realtively cheap. Why not just
make initial idxmap much bigger and be done with it.
--
^ permalink raw reply
* Re: Adding Support for SG,GSO,GRO
From: David Lamparter @ 2010-12-10 16:23 UTC (permalink / raw)
To: Michał Mirosław
Cc: David Lamparter, David Miller, bhutchings, srk, netdev,
Jens Axboe
In-Reply-To: <AANLkTi=cVufUAHn6LRs_vG-cW2cY87SdP9MOE7i5Ru09@mail.gmail.com>
On Fri, Dec 10, 2010 at 05:01:33PM +0100, Michał Mirosław wrote:
> W dniu 10 grudnia 2010 15:31 użytkownik David Lamparter
> <equinox@diac24.net> napisał:
> > On Fri, Dec 10, 2010 at 03:18:11PM +0100, Michał Mirosław wrote:
> >> I'm trying to understand the dependency because it looks artificial for me.
> > sendfile() is defined so that it works asynchronously, that means if you
> > change the data while it is in the queue, you get unpredictable results.
>
> The question is do we really want good checksum for bogus data?
The data isn't neccessarily bogus. It will be in some state inbetween
old and new. What that means is up to the application.
> Bad checksum in this case is
> actually a good thing as it clearly shows that something is broken in
> the sender and avoids accepting the data as valid at the receiving
> end.
No, because nothing is broken. sendfile() is working as advertised. The
specification of sendfile() is that it sends out data, and it that it
grabs that data at some more or less random point in time. The data is
valid. It is some data that corresponds to what the application wanted
written. It might be a "future" version of the data, but it will not be
random. Unpredictable, yes, in that you won't know where it will choose
old and where new data. But not random or broken.
-David
^ permalink raw reply
* Re: [RFC PATCH V2 5/5] Add TX zero copy in macvtap
From: Shirley Ma @ 2010-12-10 16:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: Avi Kivity, Arnd Bergmann, mst, xiaohui.xin, netdev, kvm,
linux-kernel
In-Reply-To: <1291976864.3580.7.camel@edumazet-laptop>
On Fri, 2010-12-10 at 11:27 +0100, Eric Dumazet wrote:
> You could make one atomic_add() outside of the loop, and factorize
> many
> things...
>
> atomic_add(len, &skb->sk->sk_wmem_alloc);
> skb->data_len += len;
> skb->len += len;
> skb->truesize += len;
> while (len) {
> ...
> }
Yep, thanks, will update it!
Shirley
^ permalink raw reply
* Re: Adding Support for SG,GSO,GRO
From: Eric Dumazet @ 2010-12-10 16:26 UTC (permalink / raw)
To: Michał Mirosław
Cc: David Lamparter, David Miller, bhutchings, srk, netdev,
Jens Axboe
In-Reply-To: <AANLkTi=cVufUAHn6LRs_vG-cW2cY87SdP9MOE7i5Ru09@mail.gmail.com>
Le vendredi 10 décembre 2010 à 17:01 +0100, Michał Mirosław a écrit :
> W dniu 10 grudnia 2010 15:31 użytkownik David Lamparter
> <equinox@diac24.net> napisał:
> > On Fri, Dec 10, 2010 at 03:18:11PM +0100, Michał Mirosław wrote:
> >> I'm trying to understand the dependency because it looks artificial for me.
> >
> > You have the data you want to send in the RAM, somewhere, possibly
> > scattered. The application calls sendfile(). The kernel puts the
> > transmission in the network card's queue, which might already have lots
> > of entries.
> >
> > A millisecond later - an eternity for the CPU - the card decides to do
> > the transmission.
> >
> > However, the data might have changed in the meantime.
> >
> > sendfile() is defined so that it works asynchronously, that means if you
> > change the data while it is in the queue, you get unpredictable results.
> >
> > But, what you should NOT get is packets with an invalid checksum.
> > Whatever data you are sending, it needs to have a correct checksum.
> >
> > Now, if the card does the checksum itself, everything is fine. But what
> > are you supposed to do if the card can't checksum? Call back the kernel
> > at the point where the card does the TX? That's pointless (and racy).
> > Pre-calculate the Checksum at submission time? Doesn't work, you would
> > have to make a copy of the data, so it doesn't change anymore, so the
> > checksum stays correct. But not copying the data is the whole point of
> > sendfile().
>
> The question is do we really want good checksum for bogus data?
A frame must be sent with good checksum, or you violate very basic
transport rule. You mix several layers here.
> I
> think that what matters is that good data (it had not changed between
> queuing and sending, and so the checksum does not depend on whether
> hardware or software calculated it) need to be accompanied by good
> checksum. For broken data it would be even better to not send
> anything, but that's not always possible. Bad checksum in this case is
> actually a good thing as it clearly shows that something is broken in
> the sender and avoids accepting the data as valid at the receiving
> end.
>
a crc checksum is very lazy, and not guarantee the file you received is
consistent. Is a "per frame" checksum, not a "per file" checksum. If you
want, add a MD5 sum and all be fine.
> sendfile() is supposed to replace read()/write() loops to avoid
> copying data buffers. Whatever the optimizations, it has no additional
> cavat that it might corrupt the transfer. Fixing the checksum in case
> data gets corrupted is not the right thing, I think.
>
You cannot fix the dam thing, or you MUST play VM games, that we cant to
avoid at the very beginning.
> The change of file data might happen if sendfile() submits page from
> pagecache when something writes to the file, or when an application
> modifies vmsplice()-submitted memory. In current kernel sendfile() is
> a wrapper around splice(), and so has a kernel pipe buffer between
> file and the socket. Can this hide the possible data changes?
No. Nothing in sendfile() API states that underlying file cannot change.
If we said : "We dont allow page content to change", then we _must_ add
special logic to detect a buggy application wont change the page while
we compute checksum or between this computation and final DMA to device.
That means playing VM games, and that is expensive, particularly in
multi threaded apps.
We instead say that : As we dont want to make this expensive checks, an
application is allowed to write into the page (but what should it, it
would be very stupid no ???), and a sendfile() wont be stopped/stalled
because of invalid checksum (because checksums are done after the page
content is fetched by NIC hardware)
But but but : the receiver of sendfile() get a file with possible
inconsistent content. In order to avoid this, higher level should take
locks (samba does), or make sure file is readonly.
> Unless I totally misunderstood, you say that we accept bogus data to
> being sent using sendfile(). If yes, then we might as well allow
> broken checksum (CPU calculated, before data changed and then was sent
> to network).
>
>
> If the splice/sendfile is taken out of the picture, are there any
> other scenarios, when data pages could be changed after
> ndo_start_xmit() entry and before TX DMA completion (between dma_map
> .. dma_unmap)? And is it really what can happen with splice/sendfile?
>
If you want to perform checksum before DMA to device, then you also
should copy the page into private storage (a bounce buffer), to make
sure checksum wont be invalid.
You add one copy. Your choice, but not ours.
^ permalink raw reply
* Re: [PATCH] iproute2: ip: add wilcard support for device matching
From: Eric Dumazet @ 2010-12-10 16:32 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Octavian Purdila, netdev, Lucian Adrian Grijincu, Vlad Dogaru
In-Reply-To: <20101210081846.58b67f09@nehalam>
Le vendredi 10 décembre 2010 à 08:18 -0800, Stephen Hemminger a écrit :
> On Fri, 10 Dec 2010 16:58:12 +0200
> Octavian Purdila <opurdila@ixiacom.com> wrote:
>
> > Allow the users to specify a wildcard when selecting a device:
> >
> > $ ip set link dev dummy* up
> >
> > We do this by expanding the original command line in multiple lines
> > which we then feed via a pipe to a forked ip processed run in batch
> > mode.
> >
>
>
> Seems like feature creep. Can't you do this with bash completion
> script instead.
> -
furthermore, "*" is allowed in a device name
ip link add link bond0 "vlan*" txqueuelen 100 type vlan id 999
$ ifconfig "vlan*"
vlan* Link encap:Ethernet HWaddr 00:1E:0B:EC:D3:D2
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
^ permalink raw reply
* Re: [RFC PATCH V2 5/5] Add TX zero copy in macvtap
From: Shirley Ma @ 2010-12-10 16:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Avi Kivity, Arnd Bergmann, mst, xiaohui.xin, netdev, kvm,
linux-kernel
In-Reply-To: <1291998355.2167.53.camel@localhost.localdomain>
On Fri, 2010-12-10 at 08:25 -0800, Shirley Ma wrote:
> On Fri, 2010-12-10 at 11:27 +0100, Eric Dumazet wrote:
> > You could make one atomic_add() outside of the loop, and factorize
> > many
> > things...
> >
> > atomic_add(len, &skb->sk->sk_wmem_alloc);
> > skb->data_len += len;
> > skb->len += len;
> > skb->truesize += len;
> > while (len) {
> > ...
> > }
>
> Yep, thanks, will update it!
Maybe I should use total_len when skb frag mapping is done, something
like:
int total_len = 0;
...
total len += len;
...
skb->data_len += total_len;
skb->len += total_len;
skb->truesize += total_len;
atomic_add(total_len, &skb->sk->sk_wmem_alloc);
Shirley
^ permalink raw reply
* Re: [RFC PATCH V2 5/5] Add TX zero copy in macvtap
From: Eric Dumazet @ 2010-12-10 16:55 UTC (permalink / raw)
To: Shirley Ma
Cc: Avi Kivity, Arnd Bergmann, mst, xiaohui.xin, netdev, kvm,
linux-kernel
In-Reply-To: <1291998355.2167.53.camel@localhost.localdomain>
Le vendredi 10 décembre 2010 à 08:25 -0800, Shirley Ma a écrit :
> On Fri, 2010-12-10 at 11:27 +0100, Eric Dumazet wrote:
> > You could make one atomic_add() outside of the loop, and factorize
> > many
> > things...
> >
> > atomic_add(len, &skb->sk->sk_wmem_alloc);
> > skb->data_len += len;
> > skb->len += len;
> > skb->truesize += len;
> > while (len) {
> > ...
> > }
>
> Yep, thanks, will update it!
Also take a look at skb_fill_page_desc() helper, and maybe
skb_add_rx_frag() too.
The atomic op should be factorized for sure, but other adds might be
done by helpers to keep code short.
^ permalink raw reply
* Re: [PATCH] Document the kernel_recvmsg() function
From: Randy Dunlap @ 2010-12-10 17:28 UTC (permalink / raw)
To: Martin Lucina; +Cc: netdev, Martin Sustrik, David S. Miller
In-Reply-To: <20101210100404.GA28580@dezo.moloch.sk>
On Fri, 10 Dec 2010 11:04:05 +0100 Martin Lucina wrote:
> [Updated and sent to the netdev mailing list, Eric thx for the pointer]
>
> Hi,
>
> so, today we spent all day figuring out how the kernel_sendmsg() function
^^^^^^^^^^^^^^
Maybe you could document that one also?? Thanks.
> *actually* works. This patch adds some documentation to help the next poor
> sod.
>
> -mato
>
> From 1a977fc0b9544c53761ba3c4c26ca1aac2018663 Mon Sep 17 00:00:00 2001
> From: Martin Lucina <mato@kotelna.sk>
> Date: Thu, 9 Dec 2010 17:11:18 +0100
> Subject: [PATCH] Document the kernel_recvmsg() function
>
> Signed-off-by: Martin Lucina <mato@kotelna.sk>
> ---
> net/socket.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/net/socket.c b/net/socket.c
> index 3ca2fd9..088fb3f 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -732,6 +732,21 @@ static int sock_recvmsg_nosec(struct socket *sock, struct msghdr *msg,
> return ret;
> }
>
> +/**
> + * kernel_recvmsg - Receive a message from a socket (kernel space)
> + * @sock: The socket to receive the message from
> + * @msg: Received message
> + * @vec: Input s/g array for message data
> + * @num: Size of input s/g array
> + * @size: Number of bytes to read
> + * @flags: Message flags (MSG_DONTWAIT, etc...)
> + *
> + * On return the msg structure contains the scatter/gather array passed in the
> + * vec argument. The array is modified so that it consists of the unfilled
> + * portion of the original array.
> + *
> + * The returned value is the total number of bytes received, or an error.
> + */
> int kernel_recvmsg(struct socket *sock, struct msghdr *msg,
> struct kvec *vec, size_t num, size_t size, int flags)
> {
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] iproute2: ip: add wilcard support for device matching
From: Octavian Purdila @ 2010-12-10 17:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, netdev, Lucian Adrian Grijincu, Vlad Dogaru
In-Reply-To: <1291998740.3580.162.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Friday 10 December 2010, 18:32:20
> Le vendredi 10 décembre 2010 à 08:18 -0800, Stephen Hemminger a écrit :
> > On Fri, 10 Dec 2010 16:58:12 +0200
> >
> > Octavian Purdila <opurdila@ixiacom.com> wrote:
> > > Allow the users to specify a wildcard when selecting a device:
> > >
> > > $ ip set link dev dummy* up
> > >
> > > We do this by expanding the original command line in multiple lines
> > > which we then feed via a pipe to a forked ip processed run in batch
> > > mode.
> >
> > Seems like feature creep. Can't you do this with bash completion
> > script instead.
This feature would make my life easier so to me its just a nice feature :)
Sure I can do it as a bash completion script but:
- bash does not run everywhere
- having it in iproute would make it available to everyone
- its userspace so the price to pay for a few more lines of code for usability
seems reasonable
- I don't know how scalable you can make the bash completion script
> furthermore, "*" is allowed in a device name
>
> ip link add link bond0 "vlan*" txqueuelen 100 type vlan id 999
>
Would allowing escaping it fix the issue? Like:
ip link add link bond0 "vlan\*" txqueuelen 100 type vlan id 999
^ permalink raw reply
* pull request: sfc-next-2.6 2010-12-10
From: Ben Hutchings @ 2010-12-10 17:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sf-linux-drivers
The following changes since commit defb3519a64141608725e2dac5a5aa9a3c644bae:
net: Abstract away all dst_entry metrics accesses. (2010-12-09 10:46:36 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next-2.6.git for-davem
These changes include the 'TX push' feature I mentioned at netconf.
When an TX queue is empty this feature allows the driver to write the
next DMA descriptor directly to the NIC, reducing latency by about 0.5
us (dependent on the system).
Ben.
Ben Hutchings (10):
sfc: Reorder struct efx_nic to separate fields by volatility
sfc: Use ACCESS_ONCE when copying efx_tx_queue::read_count
sfc: Expand/correct comments on collector behaviour and function usage
sfc: Remove redundant memory barriers between MMIOs
sfc: Add compile-time checks for correctness of paged register writes
sfc: Remove locking from implementation of efx_writeo_paged()
sfc: Use TX push whenever adding descriptors to an empty queue
sfc: Log start and end of ethtool self-test at INFO level
sfc: Remove filter table IDs from filter functions
sfc: Generalise filter spec initialisation
drivers/net/sfc/efx.h | 5 +-
drivers/net/sfc/ethtool.c | 99 ++++++++---------
drivers/net/sfc/filter.c | 252 ++++++++++++++++++++++++++++++++++--------
drivers/net/sfc/filter.h | 149 ++++++-------------------
drivers/net/sfc/io.h | 153 +++++++++++++++-----------
drivers/net/sfc/net_driver.h | 57 +++++++---
drivers/net/sfc/nic.c | 42 +++++++-
drivers/net/sfc/tx.c | 17 +++-
8 files changed, 468 insertions(+), 306 deletions(-)
--
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] iproute2: add dynamic index and name hashes
From: Octavian Purdila @ 2010-12-10 17:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Lucian Adrian Grijincu, Vlad Dogaru
In-Reply-To: <20101210082040.230a2832@nehalam>
> > };
> >
> > -static struct idxmap *idxmap[16];
>
> This is user space, and memory space is realtively cheap. Why not just
> make initial idxmap much bigger and be done with it.
Well, we can use up to 128K interfaces and hard coding it for that number
seems obscene to me :) But I guess a default like 16K is OK.
The patch also adds a name hash, is that part OK?
Thanks,
tavi
^ permalink raw reply
* Re: [PATCH] Document the kernel_recvmsg() function
From: Martin Lucina @ 2010-12-10 17:35 UTC (permalink / raw)
To: Randy Dunlap; +Cc: netdev, Martin Sustrik, David S. Miller
In-Reply-To: <20101210092836.0801f126.rdunlap@xenotime.net>
rdunlap@xenotime.net said:
> On Fri, 10 Dec 2010 11:04:05 +0100 Martin Lucina wrote:
>
> > [Updated and sent to the netdev mailing list, Eric thx for the pointer]
> >
> > Hi,
> >
> > so, today we spent all day figuring out how the kernel_sendmsg() function
>
> ^^^^^^^^^^^^^^
>
> Maybe you could document that one also?? Thanks.
Sorry, that was a typo. But yes, we'll get to kernel_sendmsg(), as soon as
we can actually test that properly...
In any case, kernel_recvmsg() appears to be the more evil of the two, since
it was not obvious at all that it modifies the pointers passed in to kvec.
-mato
^ permalink raw reply
* [PATCH net-next-2.6 01/10] sfc: Reorder struct efx_nic to separate fields by volatility
From: Ben Hutchings @ 2010-12-10 17:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1292002527.11673.14.camel@bwh-desktop>
Place the regularly updated fields (locks, MAC stats, etc.) on a
separate cache-line from fields which are mostly constant. This
should reduce cache misses for access to the latter on the data path.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/net_driver.h | 41 +++++++++++++++++++++++------------------
1 files changed, 23 insertions(+), 18 deletions(-)
diff --git a/drivers/net/sfc/net_driver.h b/drivers/net/sfc/net_driver.h
index 0d19fbf..60d6371 100644
--- a/drivers/net/sfc/net_driver.h
+++ b/drivers/net/sfc/net_driver.h
@@ -625,10 +625,8 @@ struct efx_filter_state;
* Work items do not hold and must not acquire RTNL.
* @workqueue_name: Name of workqueue
* @reset_work: Scheduled reset workitem
- * @monitor_work: Hardware monitor workitem
* @membase_phys: Memory BAR value as physical address
* @membase: Memory BAR value
- * @biu_lock: BIU (bus interface unit) lock
* @interrupt_mode: Interrupt mode
* @irq_rx_adaptive: Adaptive IRQ moderation enabled for RX event queues
* @irq_rx_moderation: IRQ moderation time for RX event queues
@@ -652,14 +650,9 @@ struct efx_filter_state;
* @int_error_count: Number of internal errors seen recently
* @int_error_expire: Time at which error count will be expired
* @irq_status: Interrupt status buffer
- * @last_irq_cpu: Last CPU to handle interrupt.
- * This register is written with the SMP processor ID whenever an
- * interrupt is handled. It is used by efx_nic_test_interrupt()
- * to verify that an interrupt has occurred.
* @irq_zero_count: Number of legacy IRQs seen with queue flags == 0
* @fatal_irq_level: IRQ level (bit number) used for serious errors
* @mtd_list: List of MTDs attached to the NIC
- * @n_rx_nodesc_drop_cnt: RX no descriptor drop count
* @nic_data: Hardware dependant state
* @mac_lock: MAC access lock. Protects @port_enabled, @phy_mode,
* @port_inhibited, efx_monitor() and efx_reconfigure_port()
@@ -672,11 +665,7 @@ struct efx_filter_state;
* @port_initialized: Port initialized?
* @net_dev: Operating system network device. Consider holding the rtnl lock
* @rx_checksum_enabled: RX checksumming enabled
- * @mac_stats: MAC statistics. These include all statistics the MACs
- * can provide. Generic code converts these into a standard
- * &struct net_device_stats.
* @stats_buffer: DMA buffer for statistics
- * @stats_lock: Statistics update lock. Serialises statistics fetches
* @mac_op: MAC interface
* @phy_type: PHY type
* @phy_op: PHY interface
@@ -694,10 +683,23 @@ struct efx_filter_state;
* @loopback_mode: Loopback status
* @loopback_modes: Supported loopback mode bitmask
* @loopback_selftest: Offline self-test private state
+ * @monitor_work: Hardware monitor workitem
+ * @biu_lock: BIU (bus interface unit) lock
+ * @last_irq_cpu: Last CPU to handle interrupt.
+ * This register is written with the SMP processor ID whenever an
+ * interrupt is handled. It is used by efx_nic_test_interrupt()
+ * to verify that an interrupt has occurred.
+ * @n_rx_nodesc_drop_cnt: RX no descriptor drop count
+ * @mac_stats: MAC statistics. These include all statistics the MACs
+ * can provide. Generic code converts these into a standard
+ * &struct net_device_stats.
+ * @stats_lock: Statistics update lock. Serialises statistics fetches
*
* This is stored in the private area of the &struct net_device.
*/
struct efx_nic {
+ /* The following fields should be written very rarely */
+
char name[IFNAMSIZ];
struct pci_dev *pci_dev;
const struct efx_nic_type *type;
@@ -705,10 +707,9 @@ struct efx_nic {
struct workqueue_struct *workqueue;
char workqueue_name[16];
struct work_struct reset_work;
- struct delayed_work monitor_work;
resource_size_t membase_phys;
void __iomem *membase;
- spinlock_t biu_lock;
+
enum efx_int_mode interrupt_mode;
bool irq_rx_adaptive;
unsigned int irq_rx_moderation;
@@ -735,7 +736,6 @@ struct efx_nic {
unsigned long int_error_expire;
struct efx_buffer irq_status;
- volatile signed int last_irq_cpu;
unsigned irq_zero_count;
unsigned fatal_irq_level;
@@ -743,8 +743,6 @@ struct efx_nic {
struct list_head mtd_list;
#endif
- unsigned n_rx_nodesc_drop_cnt;
-
void *nic_data;
struct mutex mac_lock;
@@ -756,9 +754,7 @@ struct efx_nic {
struct net_device *net_dev;
bool rx_checksum_enabled;
- struct efx_mac_stats mac_stats;
struct efx_buffer stats_buffer;
- spinlock_t stats_lock;
struct efx_mac_operations *mac_op;
@@ -784,6 +780,15 @@ struct efx_nic {
void *loopback_selftest;
struct efx_filter_state *filter_state;
+
+ /* The following fields may be written more often */
+
+ struct delayed_work monitor_work ____cacheline_aligned_in_smp;
+ spinlock_t biu_lock;
+ volatile signed int last_irq_cpu;
+ unsigned n_rx_nodesc_drop_cnt;
+ struct efx_mac_stats mac_stats;
+ spinlock_t stats_lock;
};
static inline int efx_dev_registered(struct efx_nic *efx)
--
1.7.3.2
--
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 related
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