* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-02 18:20 UTC (permalink / raw)
To: Shirley Ma
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <1296661371.25430.13.camel@localhost.localdomain>
On Wed, Feb 02, 2011 at 07:42:51AM -0800, Shirley Ma wrote:
> On Wed, 2011-02-02 at 12:49 +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 01, 2011 at 11:33:49PM -0800, Shirley Ma wrote:
> > > On Tue, 2011-02-01 at 23:14 -0800, Shirley Ma wrote:
> > > > w/i guest change, I played around the parameters,for example: I
> > could
> > > > get 3.7Gb/s with 42% CPU BW increasing from 2.5Gb/s for 1K message
> > > > size,
> > > > w/i dropping packet, I was able to get up to 6.2Gb/s with similar
> > CPU
> > > > usage.
> > >
> > > I meant w/o guest change, only vhost changes. Sorry about that.
> > >
> > > Shirley
> >
> > Ah, excellent. What were the parameters?
>
> I used half of the ring size 129 for packet counters,
> but the
> performance is still not as good as dropping packets on guest, 3.7 Gb/s
> vs. 6.2Gb/s.
>
> Shirley
How many packets and bytes per interrupt are sent?
Also, what about other values for the counters and other counters?
What does your patch do? Just drop packets instead of
stopping the interface?
To have an understanding when should we drop packets
in the guest, we need to know *why* does it help.
Otherwise, how do we know it will work for others?
Note that qdisc will drop packets when it overruns -
so what is different? Also, are we over-running some other queue
somewhere?
--
MST
^ permalink raw reply
* [PATCH v4 2/2] iproute2: support device group semantics
From: Vlad Dogaru @ 2011-02-02 18:23 UTC (permalink / raw)
To: netdev; +Cc: Vlad Dogaru, Stephen Hemminger, Patrick McHardy
In-Reply-To: <1296671021-24421-1-git-send-email-ddvlad@rosedu.org>
Add the group keyword to ip link set, which has the following meaning:
If both a group and a device name are pressent, we change the device's
group to the specified one. If only a group is present, then the
operation specified by the rest of the command should apply on an entire
group, not a single device.
So, to set eth0 to the default group, one would use
ip link set dev eth0 group default
Conversely, to set all the devices in the default group down, use
ip link set group default down
Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>
---
include/utils.h | 3 ++-
ip/iplink.c | 40 +++++++++++++++++++++++++++++++++++++---
ip/link_veth.c | 3 ++-
man/man8/ip.8 | 19 +++++++++++++++++--
4 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/include/utils.h b/include/utils.h
index 3da6998..595a7d6 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -151,5 +151,6 @@ extern int makeargs(char *line, char *argv[], int maxargs);
struct iplink_req;
int iplink_parse(int argc, char **argv, struct iplink_req *req,
- char **name, char **type, char **link, char **dev);
+ char **name, char **type, char **link, char **dev,
+ int *group);
#endif /* __UTILS_H__ */
diff --git a/ip/iplink.c b/ip/iplink.c
index 97a960b..8160855 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -51,7 +51,7 @@ void iplink_usage(void)
fprintf(stderr, " type TYPE [ ARGS ]\n");
fprintf(stderr, " ip link delete DEV type TYPE [ ARGS ]\n");
fprintf(stderr, "\n");
- fprintf(stderr, " ip link set DEVICE [ { up | down } ]\n");
+ fprintf(stderr, " ip link set { dev DEVICE | group DEVGROUP } [ { up | down } ]\n");
} else
fprintf(stderr, "Usage: ip link set DEVICE [ { up | down } ]\n");
@@ -244,7 +244,7 @@ int iplink_parse_vf(int vf, int *argcp, char ***argvp,
int iplink_parse(int argc, char **argv, struct iplink_req *req,
- char **name, char **type, char **link, char **dev)
+ char **name, char **type, char **link, char **dev, int *group)
{
int ret, len;
char abuf[32];
@@ -253,6 +253,7 @@ int iplink_parse(int argc, char **argv, struct iplink_req *req,
int netns = -1;
int vf = -1;
+ *group = -1;
ret = argc;
while (argc > 0) {
@@ -383,6 +384,12 @@ int iplink_parse(int argc, char **argv, struct iplink_req *req,
*argv, strlen(*argv));
argc--; argv++;
break;
+ } else if (strcmp(*argv, "group") == 0) {
+ NEXT_ARG();
+ if (*group != -1)
+ duparg("group", *argv);
+ if (rtnl_group_a2n(group, *argv))
+ invarg("Invalid \"group\" value\n", *argv);
} else {
if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
@@ -406,6 +413,7 @@ static int iplink_modify(int cmd, unsigned int flags, int argc, char **argv)
char *name = NULL;
char *link = NULL;
char *type = NULL;
+ int group;
struct link_util *lu = NULL;
struct iplink_req req;
int ret;
@@ -417,12 +425,38 @@ static int iplink_modify(int cmd, unsigned int flags, int argc, char **argv)
req.n.nlmsg_type = cmd;
req.i.ifi_family = preferred_family;
- ret = iplink_parse(argc, argv, &req, &name, &type, &link, &dev);
+ ret = iplink_parse(argc, argv, &req, &name, &type, &link, &dev, &group);
if (ret < 0)
return ret;
argc -= ret;
argv += ret;
+
+ if (group != -1) {
+ if (dev)
+ addattr_l(&req.n, sizeof(req), IFLA_GROUP,
+ &group, sizeof(group));
+ else {
+ if (argc) {
+ fprintf(stderr, "Garbage instead of arguments "
+ "\"%s ...\". Try \"ip link "
+ "help\".\n", *argv);
+ return -1;
+ }
+ if (flags & NLM_F_CREATE) {
+ fprintf(stderr, "group cannot be used when "
+ "creating devices.\n");
+ return -1;
+ }
+
+ req.i.ifi_index = 0;
+ addattr32(&req.n, sizeof(req), IFLA_GROUP, group);
+ if (rtnl_talk(&rth, &req.n, 0, 0, NULL, NULL, NULL) < 0)
+ exit(2);
+ return 0;
+ }
+ }
+
ll_init_map(&rth);
if (type) {
diff --git a/ip/link_veth.c b/ip/link_veth.c
index 9f5e871..3d19b01 100644
--- a/ip/link_veth.c
+++ b/ip/link_veth.c
@@ -30,6 +30,7 @@ static int veth_parse_opt(struct link_util *lu, int argc, char **argv,
char *name, *type, *link, *dev;
int err, len;
struct rtattr * data;
+ int group;
if (strcmp(argv[0], "peer") != 0) {
usage();
@@ -42,7 +43,7 @@ static int veth_parse_opt(struct link_util *lu, int argc, char **argv,
hdr->nlmsg_len += sizeof(struct ifinfomsg);
err = iplink_parse(argc - 1, argv + 1, (struct iplink_req *)hdr,
- &name, &type, &link, &dev);
+ &name, &type, &link, &dev, &group);
if (err < 0)
return err;
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 730788a..8f82842 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -55,8 +55,10 @@ ip \- show / manipulate routing, devices, policy routing and tunnels
.RI "[ " ARGS " ]"
.ti -8
-.BI "ip link set " DEVICE
-.RB "{ " up " | " down " | " arp " { " on " | " off " } |"
+.BR "ip link set " {
+.IR DEVICE " | "
+.BI "group " GROUP
+.RB "} { " up " | " down " | " arp " { " on " | " off " } |"
.br
.BR promisc " { " on " | " off " } |"
.br
@@ -930,6 +932,13 @@ specifies network device to operate on. When configuring SR-IOV Virtual Fuction
device.
.TP
+.BI group " GROUP "
+.I GROUP
+has a dual role: If both group and dev are present, then move the device to the
+specified group. If only a group is specified, then the command operates on
+all devices in that group.
+
+.TP
.BR up " and " down
change the state of the device to
.B UP
@@ -996,6 +1005,12 @@ move the device to the network namespace associated with the process
give the device a symbolic name for easy reference.
.TP
+.BI group " GROUP"
+specify the group the device belongs to.
+The available groups are listed in file
+.BR "/etc/iproute2/group" .
+
+.TP
.BI vf " NUM"
specify a Virtual Function device to be configured. The associated PF device
must be specified using the
--
1.7.1
^ permalink raw reply related
* [PATCH v4 0/2] iproute2: support for device groups
From: Vlad Dogaru @ 2011-02-02 18:23 UTC (permalink / raw)
To: netdev; +Cc: Vlad Dogaru, Stephen Hemminger, Patrick McHardy
This patch series adds userspace support for network device groups.
There is support for setting device groups, listing only interfaces of a
specific group, and setting basic device parameters for all interfaces
in a group.
Changes since version 3:
* drop devgroup keyword. There is a single keyword for specifying
groups now.
* store group names internally as a hash, similar to routing table
names. This is more efficient for batch mode operations.
Changes since version 2:
* groups now have names. The mapping between names and numbers (which
are used by the kernel) is in /etc/iproute2/group.
* the ip man page and usage display function have been updated to
reflect the new functionality.
Changes since version 1:
* a single attribute is used for both setting the group of a device and
manipulating an entire group.
Vlad Dogaru (2):
iproute2: support listing devices by group
iproute2: support device group semantics
etc/iproute2/group | 2 +
include/linux/if_link.h | 1 +
include/linux/netdevice.h | 2 +-
include/rt_names.h | 1 +
include/utils.h | 3 +-
ip/ipaddress.c | 14 ++++++++++++
ip/iplink.c | 42 ++++++++++++++++++++++++++++++++++---
ip/link_veth.c | 3 +-
lib/rt_names.c | 50 +++++++++++++++++++++++++++++++++++++++++++++
man/man8/ip.8 | 30 +++++++++++++++++++++++---
10 files changed, 137 insertions(+), 11 deletions(-)
create mode 100644 etc/iproute2/group
^ permalink raw reply
* [PATCH v4 1/2] iproute2: support listing devices by group
From: Vlad Dogaru @ 2011-02-02 18:23 UTC (permalink / raw)
To: netdev; +Cc: Vlad Dogaru, Stephen Hemminger, Patrick McHardy
In-Reply-To: <1296671021-24421-1-git-send-email-ddvlad@rosedu.org>
User can specify device group to list by using the group keyword:
ip link show group test
If no group is specified, 0 (default) is implied.
Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>
---
etc/iproute2/group | 2 +
include/linux/if_link.h | 1 +
include/linux/netdevice.h | 2 +-
include/rt_names.h | 1 +
ip/ipaddress.c | 14 ++++++++++++
ip/iplink.c | 2 +-
lib/rt_names.c | 50 +++++++++++++++++++++++++++++++++++++++++++++
man/man8/ip.8 | 11 ++++++++-
8 files changed, 79 insertions(+), 4 deletions(-)
create mode 100644 etc/iproute2/group
diff --git a/etc/iproute2/group b/etc/iproute2/group
new file mode 100644
index 0000000..6f000b2
--- /dev/null
+++ b/etc/iproute2/group
@@ -0,0 +1,2 @@
+# device group names
+0 default
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index e87456c..54d05f9 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -135,6 +135,7 @@ enum {
IFLA_VF_PORTS,
IFLA_PORT_SELF,
IFLA_AF_SPEC,
+ IFLA_GROUP,
__IFLA_MAX
};
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index bec4e23..ad2e34d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -33,7 +33,7 @@
#define MAX_ADDR_LEN 32 /* Largest hardware address length */
-
+#define INIT_NETDEV_GROUP 0 /* Initial group net devices belong to */
/* Media selection options. */
enum {
diff --git a/include/rt_names.h b/include/rt_names.h
index 07a10e0..e5dbd45 100644
--- a/include/rt_names.h
+++ b/include/rt_names.h
@@ -13,6 +13,7 @@ int rtnl_rtscope_a2n(__u32 *id, char *arg);
int rtnl_rttable_a2n(__u32 *id, char *arg);
int rtnl_rtrealm_a2n(__u32 *id, char *arg);
int rtnl_dsfield_a2n(__u32 *id, char *arg);
+int rtnl_group_a2n(int *id, char *arg);
const char *inet_proto_n2a(int proto, char *buf, int len);
int inet_proto_a2n(char *buf);
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index a775ecd..e4748e3 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -49,6 +49,7 @@ static struct
char *flushb;
int flushp;
int flushe;
+ int group;
} filter;
static int do_link;
@@ -246,6 +247,12 @@ int print_linkinfo(const struct sockaddr_nl *who,
fnmatch(filter.label, RTA_DATA(tb[IFLA_IFNAME]), 0))
return 0;
+ if (tb[IFLA_GROUP]) {
+ int group = *(int*)RTA_DATA(tb[IFLA_GROUP]);
+ if (group != filter.group)
+ return -1;
+ }
+
if (n->nlmsg_type == RTM_DELLINK)
fprintf(fp, "Deleted ");
@@ -718,9 +725,12 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
if (filter.family == AF_UNSPEC)
filter.family = preferred_family;
+ filter.group = INIT_NETDEV_GROUP;
+
if (flush) {
if (argc <= 0) {
fprintf(stderr, "Flush requires arguments.\n");
+
return -1;
}
if (filter.family == AF_PACKET) {
@@ -779,6 +789,10 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
} else if (strcmp(*argv, "label") == 0) {
NEXT_ARG();
filter.label = *argv;
+ } else if (strcmp(*argv, "group") == 0) {
+ NEXT_ARG();
+ if (rtnl_group_a2n(&filter.group, *argv))
+ invarg("Invalid \"group\" value\n", *argv);
} else {
if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
diff --git a/ip/iplink.c b/ip/iplink.c
index cb2c4f5..97a960b 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -71,7 +71,7 @@ void iplink_usage(void)
fprintf(stderr, " [ vf NUM [ mac LLADDR ]\n");
fprintf(stderr, " [ vlan VLANID [ qos VLAN-QOS ] ]\n");
fprintf(stderr, " [ rate TXRATE ] ] \n");
- fprintf(stderr, " ip link show [ DEVICE ]\n");
+ fprintf(stderr, " ip link show [ DEVICE | group GROUP ]\n");
if (iplink_have_newlink()) {
fprintf(stderr, "\n");
diff --git a/lib/rt_names.c b/lib/rt_names.c
index 52edfe3..30d43cd 100644
--- a/lib/rt_names.c
+++ b/lib/rt_names.c
@@ -447,3 +447,53 @@ int rtnl_dsfield_a2n(__u32 *id, char *arg)
return 0;
}
+
+static struct rtnl_hash_entry dflt_group_entry = { .id = 0, .name = "default" };
+
+static struct rtnl_hash_entry * rtnl_group_hash[256] = {
+ [0] = &dflt_group_entry,
+};
+
+static int rtnl_group_init;
+
+static void rtnl_group_initialize(void)
+{
+ rtnl_group_init = 1;
+ rtnl_hash_initialize("/etc/iproute2/group",
+ rtnl_group_hash, 256);
+}
+
+int rtnl_group_a2n(int *id, char *arg)
+{
+ static char *cache = NULL;
+ static unsigned long res;
+ struct rtnl_hash_entry *entry;
+ char *end;
+ int i;
+
+ if (cache && strcmp(cache, arg) == 0) {
+ *id = res;
+ return 0;
+ }
+
+ if (!rtnl_group_init)
+ rtnl_group_initialize();
+
+ for (i=0; i<256; i++) {
+ entry = rtnl_group_hash[i];
+ while (entry && strcmp(entry->name, arg))
+ entry = entry->next;
+ if (entry) {
+ cache = entry->name;
+ res = entry->id;
+ *id = res;
+ return 0;
+ }
+ }
+
+ i = strtol(arg, &end, 0);
+ if (!end || end == arg || *end || i < 0)
+ return -1;
+ *id = i;
+ return 0;
+}
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 8d55fa9..730788a 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -99,7 +99,9 @@ ip \- show / manipulate routing, devices, policy routing and tunnels
.ti -8
.B ip link show
-.RI "[ " DEVICE " ]"
+.RI "[ " DEVICE " | "
+.B group
+.IR GROUP " ]"
.ti -8
.BR "ip addr" " { " add " | " del " } "
@@ -1056,7 +1058,12 @@ call.
.BI dev " NAME " (default)
.I NAME
specifies the network device to show.
-If this argument is omitted all devices are listed.
+If this argument is omitted all devices in the default group are listed.
+
+.TP
+.BI group " GROUP "
+.I GROUP
+specifies what group of devices to show.
.TP
.B up
--
1.7.1
^ permalink raw reply related
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-02 18:26 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <20110202182024.GA14257@redhat.com>
On Wed, 2011-02-02 at 20:20 +0200, Michael S. Tsirkin wrote:
> How many packets and bytes per interrupt are sent?
> Also, what about other values for the counters and other counters?
>
> What does your patch do? Just drop packets instead of
> stopping the interface?
>
> To have an understanding when should we drop packets
> in the guest, we need to know *why* does it help.
> Otherwise, how do we know it will work for others?
> Note that qdisc will drop packets when it overruns -
> so what is different? Also, are we over-running some other queue
> somewhere?
Agreed. I am trying to put more debugging output to look for all these
answers.
Shirley
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-02 18:27 UTC (permalink / raw)
To: Shirley Ma
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <1296670311.25430.49.camel@localhost.localdomain>
On Wed, Feb 02, 2011 at 10:11:51AM -0800, Shirley Ma wrote:
> On Wed, 2011-02-02 at 19:32 +0200, Michael S. Tsirkin wrote:
> > OK, but this should have no effect with a vhost patch
> > which should ensure that we don't get an interrupt
> > until the queue is at least half empty.
> > Right?
>
> There should be some coordination between guest and vhost.
What kind of coordination? With a patched vhost, and a full ring.
you should get an interrupt per 100 packets.
Is this what you see? And if yes, isn't the guest patch
doing nothing then?
> We shouldn't
> count the TX packets when netif queue is enabled since next guest TX
> xmit will free any used buffers in vhost. We need to be careful here in
> case we miss the interrupts when netif queue has stopped.
>
> However we can't change old guest so we can test the patches separately
> for guest only, vhost only, and the combination.
>
> > > >
> > > > Yes, it seems unrelated to tx interrupts.
> > >
> > > The issue is more likely related to latency.
> >
> > Could be. Why do you think so?
>
> Since I played with latency hack, I can see performance difference for
> different latency.
Which hack was that?
> > > Do you have anything in
> > > mind on how to reduce vhost latency?
> > >
> > > Thanks
> > > Shirley
> >
> > Hmm, bypassing the bridge might help a bit.
> > Are you using tap+bridge or macvtap?
>
> I am using tap+bridge for TCP_RR test, I think Steven tested macvtap
> before. He might have some data from his workload performance
> measurement.
>
> Shirley
^ permalink raw reply
* Re: af_unix unix_getname: return size for unnamed sockets too small?
From: Eric W. Biederman @ 2011-02-02 18:59 UTC (permalink / raw)
To: Marcus Meissner; +Cc: davem, eric.dumazet, netdev, linux-kernel, gorcunov
In-Reply-To: <20110202174015.GB25515@suse.de>
Marcus Meissner <meissner@suse.de> writes:
> Hi,
>
> In net/unix/af_unix.c::unix_getname() there is a small problem:
>
> if (!u->addr) {
> sunaddr->sun_family = AF_UNIX;
> sunaddr->sun_path[0] = 0; // not copied out
> *uaddr_len = sizeof(short);
> } else {
> struct unix_address *addr = u->addr;
>
> *uaddr_len = addr->len;
> memcpy(sunaddr, addr->name, *uaddr_len);
> }
>
> The if (!u->addr) case will not copy out the \0 in the sun_path, as
> uaddr_len is just the size of sun_family.
>
> (Shown by socat crashing after decoding gethostname return and expected
> sun_path to be a valid string (and not seeing the \0)).
Perhaps my memory is scrambled but the sun_path has embedded '\0's so I
don't see how a correct application can expect the path to be '\0'
terminated. An application should be looking at the length we give it.
> Should it perhaps be *uaddr_len = sizeof(short)+sizeof(char)?
I don't think so.
Eric
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-02 19:29 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <20110202182720.GB14257@redhat.com>
On Wed, 2011-02-02 at 20:27 +0200, Michael S. Tsirkin wrote:
> On Wed, Feb 02, 2011 at 10:11:51AM -0800, Shirley Ma wrote:
> > On Wed, 2011-02-02 at 19:32 +0200, Michael S. Tsirkin wrote:
> > > OK, but this should have no effect with a vhost patch
> > > which should ensure that we don't get an interrupt
> > > until the queue is at least half empty.
> > > Right?
> >
> > There should be some coordination between guest and vhost.
>
> What kind of coordination? With a patched vhost, and a full ring.
> you should get an interrupt per 100 packets.
> Is this what you see? And if yes, isn't the guest patch
> doing nothing then?
vhost_signal won't be able send any TX interrupts to guest when guest TX
interrupt is disabled. Guest TX interrupt is only enabled when running
out of descriptors.
> > We shouldn't
> > count the TX packets when netif queue is enabled since next guest TX
> > xmit will free any used buffers in vhost. We need to be careful here
> in
> > case we miss the interrupts when netif queue has stopped.
> >
> > However we can't change old guest so we can test the patches
> separately
> > for guest only, vhost only, and the combination.
> >
> > > > >
> > > > > Yes, it seems unrelated to tx interrupts.
> > > >
> > > > The issue is more likely related to latency.
> > >
> > > Could be. Why do you think so?
> >
> > Since I played with latency hack, I can see performance difference
> for
> > different latency.
>
> Which hack was that?
I tried to accumulate multiple guest to host notifications for TX xmits,
it did help multiple streams TCP_RR results; I also forced vhost
handle_tx to handle more packets; both hack seemed help.
Thanks
Shirley
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-02 20:17 UTC (permalink / raw)
To: Shirley Ma
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <1296674975.25430.59.camel@localhost.localdomain>
On Wed, Feb 02, 2011 at 11:29:35AM -0800, Shirley Ma wrote:
> On Wed, 2011-02-02 at 20:27 +0200, Michael S. Tsirkin wrote:
> > On Wed, Feb 02, 2011 at 10:11:51AM -0800, Shirley Ma wrote:
> > > On Wed, 2011-02-02 at 19:32 +0200, Michael S. Tsirkin wrote:
> > > > OK, but this should have no effect with a vhost patch
> > > > which should ensure that we don't get an interrupt
> > > > until the queue is at least half empty.
> > > > Right?
> > >
> > > There should be some coordination between guest and vhost.
> >
> > What kind of coordination? With a patched vhost, and a full ring.
> > you should get an interrupt per 100 packets.
> > Is this what you see? And if yes, isn't the guest patch
> > doing nothing then?
>
> vhost_signal won't be able send any TX interrupts to guest when guest TX
> interrupt is disabled. Guest TX interrupt is only enabled when running
> out of descriptors.
Well, this is also the only case where the queue is stopped, no?
> > > We shouldn't
> > > count the TX packets when netif queue is enabled since next guest TX
> > > xmit will free any used buffers in vhost. We need to be careful here
> > in
> > > case we miss the interrupts when netif queue has stopped.
> > >
> > > However we can't change old guest so we can test the patches
> > separately
> > > for guest only, vhost only, and the combination.
> > >
> > > > > >
> > > > > > Yes, it seems unrelated to tx interrupts.
> > > > >
> > > > > The issue is more likely related to latency.
> > > >
> > > > Could be. Why do you think so?
> > >
> > > Since I played with latency hack, I can see performance difference
> > for
> > > different latency.
> >
> > Which hack was that?
>
> I tried to accumulate multiple guest to host notifications for TX xmits,
> it did help multiple streams TCP_RR results;
I don't see a point to delay used idx update, do you?
So delaying just signal seems better, right?
> I also forced vhost
> handle_tx to handle more packets; both hack seemed help.
>
> Thanks
> Shirley
Haven't noticed that part, how does your patch make it
handle more packets?
--
MST
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-02 21:03 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <20110202201731.GB15150@redhat.com>
On Wed, 2011-02-02 at 22:17 +0200, Michael S. Tsirkin wrote:
> Well, this is also the only case where the queue is stopped, no?
Yes. I got some debugging data, I saw that sometimes there were so many
packets were waiting for free in guest between vhost_signal & guest xmit
callback. Looks like the time spent too long from vhost_signal to guest
xmit callback?
> > I tried to accumulate multiple guest to host notifications for TX
> xmits,
> > it did help multiple streams TCP_RR results;
> I don't see a point to delay used idx update, do you?
It might cause per vhost handle_tx processed more packets.
> So delaying just signal seems better, right?
I think I need to define the test matrix to collect data for TX xmit
from guest to host here for different tests.
Data to be collected:
---------------------
1. kvm_stat for VM, I/O exits
2. cpu utilization for both guest and host
3. cat /proc/interrupts on guest
4. packets rate from vhost handle_tx per loop
5. guest netif queue stop rate
6. how many packets are waiting for free between vhost signaling and
guest callback
7. performance results
Test
----
1. TCP_STREAM single stream test for 1K to 4K message size
2. TCP_RR (64 instance test): 128 - 1K request/response size
Different hacks
---------------
1. Base line data ( with the patch to fix capacity check first,
free_old_xmit_skbs returns number of skbs)
2. Drop packet data (will put some debugging in generic networking code)
3. Delay guest netif queue wake up until certain descriptors (1/2 ring
size, 1/4 ring size...) are available once the queue has stopped.
4. Accumulate more packets per vhost signal in handle_tx?
5. 3 & 4 combinations
6. Accumulate more packets per guest kick() (TCP_RR) by adding a timer?
7. Accumulate more packets per vhost handle_tx() by adding some delay?
> Haven't noticed that part, how does your patch make it
handle more packets?
Added a delay in handle_tx().
What else?
It would take sometimes to do this.
Shirley
^ permalink raw reply
* [PATCH net-2.6] gro: reset skb_iif on reuse
From: andy @ 2011-02-02 21:27 UTC (permalink / raw)
To: netdev
Like Herbert's change from a few days ago:
66c46d741e2e60f0e8b625b80edb0ab820c46d7a gro: Reset dev pointer on reuse
this may not be necessary at this point, but we should still clean up
the skb->skb_iif. If not we may end up with an invalid valid for
skb->skb_iif when the skb is reused and the check is done in
__netif_receive_skb.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
net/core/dev.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 4c90789..b6d0bf8 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3426,6 +3426,7 @@ static void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb)
skb_reserve(skb, NET_IP_ALIGN - skb_headroom(skb));
skb->vlan_tci = 0;
skb->dev = napi->dev;
+ skb->skb_iif = 0;
napi->skb = skb;
}
--
1.7.3.2
^ permalink raw reply related
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-02 21:20 UTC (permalink / raw)
To: Shirley Ma
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <1296680585.25430.98.camel@localhost.localdomain>
On Wed, Feb 02, 2011 at 01:03:05PM -0800, Shirley Ma wrote:
> On Wed, 2011-02-02 at 22:17 +0200, Michael S. Tsirkin wrote:
> > Well, this is also the only case where the queue is stopped, no?
> Yes. I got some debugging data, I saw that sometimes there were so many
> packets were waiting for free in guest between vhost_signal & guest xmit
> callback.
What does this mean?
> Looks like the time spent too long from vhost_signal to guest
> xmit callback?
> > > I tried to accumulate multiple guest to host notifications for TX
> > xmits,
> > > it did help multiple streams TCP_RR results;
> > I don't see a point to delay used idx update, do you?
>
> It might cause per vhost handle_tx processed more packets.
I don't understand. It's a couple of writes - what is the issue?
> > So delaying just signal seems better, right?
>
> I think I need to define the test matrix to collect data for TX xmit
> from guest to host here for different tests.
>
> Data to be collected:
> ---------------------
> 1. kvm_stat for VM, I/O exits
> 2. cpu utilization for both guest and host
> 3. cat /proc/interrupts on guest
> 4. packets rate from vhost handle_tx per loop
> 5. guest netif queue stop rate
> 6. how many packets are waiting for free between vhost signaling and
> guest callback
> 7. performance results
>
> Test
> ----
> 1. TCP_STREAM single stream test for 1K to 4K message size
> 2. TCP_RR (64 instance test): 128 - 1K request/response size
>
> Different hacks
> ---------------
> 1. Base line data ( with the patch to fix capacity check first,
> free_old_xmit_skbs returns number of skbs)
>
> 2. Drop packet data (will put some debugging in generic networking code)
>
> 3. Delay guest netif queue wake up until certain descriptors (1/2 ring
> size, 1/4 ring size...) are available once the queue has stopped.
>
> 4. Accumulate more packets per vhost signal in handle_tx?
>
> 5. 3 & 4 combinations
>
> 6. Accumulate more packets per guest kick() (TCP_RR) by adding a timer?
>
> 7. Accumulate more packets per vhost handle_tx() by adding some delay?
>
> > Haven't noticed that part, how does your patch make it
> handle more packets?
>
> Added a delay in handle_tx().
>
> What else?
>
> It would take sometimes to do this.
>
> Shirley
Need to think about this.
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] IPVS build fixes and clean-ups
From: Simon Horman @ 2011-02-02 21:39 UTC (permalink / raw)
To: Patrick McHardy
Cc: Randy Dunlap, netdev, linux-next, linux-kernel, lvs-devel,
Stephen Rothwell, Hans Schillstrom
In-Reply-To: <4D4840BC.4050303@trash.net>
On Tue, Feb 01, 2011 at 06:19:56PM +0100, Patrick McHardy wrote:
> Am 01.02.2011 18:05, schrieb Randy Dunlap:
> > On 02/01/11 02:04, Simon Horman wrote:
> >> On Tue, Feb 01, 2011 at 03:06:37PM +1100, Simon Horman wrote:
> >>> On Mon, Jan 31, 2011 at 04:50:09PM -0800, Randy Dunlap wrote:
> >>>> On Tue, 1 Feb 2011 11:14:11 +1100 Simon Horman wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> This short patch series addresses two linux-next build problems
> >>>>> raised by Randy Dunlap:
> >>>>>
> >>>>> * net/netfilter/ipvs/ip_vs_core.c:1891: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'unsigned int'
> >>>>> * ERROR: "unregister_net_sysctl_table" [net/netfilter/ipvs/ip_vs.ko]
> >>>>> ERROR: "register_net_sysctl_table" [net/netfilter/ipvs/ip_vs.ko] undefined!
> >>>>>
> >>>>> The remainder of the changset is cleanups that I noticed along the way.
> >>>>
> >>>> These 4 patches build successfully for me.
> >>>> However, I do see these warnings (sorry I missed them earlier):
> >>>>
> >>>> WARNING: net/netfilter/ipvs/ip_vs.o(.init.text+0x161): Section mismatch in reference from the function init_module() to the function .exit.text:ip_vs_sync_cleanup()
> >>>> WARNING: net/netfilter/ipvs/ip_vs.o(.init.text+0x161): Section mismatch in reference from the function init_module() to the function .exit.text:ip_vs_sync_cleanup()
> >>>
> >>> Thanks, I'll look into that. I will be travelling for a good portion of the
> >>> next day and a bit so I apologise in advance if that delays my next patch.
> >>
> >> Hi,
> >>
> >> I the following patch seems to be the right fix for this to me.
> >> I will send an amended pull request.
> >>
> >> IPVS: Remove ip_vs_sync_cleanup from section __exit
> >>
> >> ip_vs_sync_cleanup() may be called from ip_vs_init() on error
> >> and thus needs to be accesible from section __init
> >>
> >> Reporte-by: Randy Dunlap <randy.dunlap@oracle.com>
> > Reported-by:
> >
> >> Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
>
> Thanks, since Simon is travelling, I'll apply the patches now
> with your and Hans's Acks and will push them to Dave later.
Thanks, I've finished travelling now :-)
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-02 21:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <20110202212047.GD15150@redhat.com>
On Wed, 2011-02-02 at 23:20 +0200, Michael S. Tsirkin wrote:
> > On Wed, 2011-02-02 at 22:17 +0200, Michael S. Tsirkin wrote:
> > > Well, this is also the only case where the queue is stopped, no?
> > Yes. I got some debugging data, I saw that sometimes there were so
> many
> > packets were waiting for free in guest between vhost_signal & guest
> xmit
> > callback.
>
> What does this mean?
Let's look at the sequence here:
guest start_xmit()
xmit_skb()
if ring is full,
enable_cb()
guest skb_xmit_done()
disable_cb,
printk free_old_xmit_skbs <-- it was between more than 1/2 to
full ring size
printk vq->num_free
vhost handle_tx()
if (guest interrupt is enabled)
signal guest to free xmit buffers
So between guest queue full/stopped queue/enable call back to guest
receives the callback from host to free_old_xmit_skbs, there were about
1/2 to full ring size descriptors available. I thought there were only a
few. (I disabled your vhost patch for this test.)
> > Looks like the time spent too long from vhost_signal to guest
> > xmit callback?
>
>
>
> > > > I tried to accumulate multiple guest to host notifications for
> TX
> > > xmits,
> > > > it did help multiple streams TCP_RR results;
> > > I don't see a point to delay used idx update, do you?
> >
> > It might cause per vhost handle_tx processed more packets.
>
> I don't understand. It's a couple of writes - what is the issue?
Oh, handle_tx could process more packets per loop for multiple streams
TCP_RR case. I need to print out the data rate per loop to confirm this.
Shirley
^ permalink raw reply
* Re: [PATCH] ipv4: Remove fib_hash.
From: David Miller @ 2011-02-02 21:51 UTC (permalink / raw)
To: shemminger; +Cc: eric.dumazet, netdev
In-Reply-To: <20110202082921.7eee82e0@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 2 Feb 2011 08:29:21 -0800
> For the case of small devices, what about keeping fib_hash as option
> under CONFIG_EMBEDDED. And remove all the magic resizing of hash table.
> Get back to something with really small size.
That's still going to be ~20,000 lines of code kept in the tree
duplicating functionality.
Sorry, no.
^ permalink raw reply
* pull request: wireless-next-2.6 2011-02-02
From: John W. Linville @ 2011-02-02 21:53 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
Here we have another big batch of updates destined for 2.6.39.
A highlight is AP mode support for the wl12xx driver. There are
also the usual updates to ath5k, ath9k, iwlwifi, rt2x00, and others.
Also included are some wireless-2.6 pulls to correct for some build breakage.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 2ba451421b23636c45fabfa522858c5c124b3673:
bnx2x, cnic: Consolidate iSCSI/FCoE shared mem logic in bnx2x (2011-01-31 20:44:46 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Arik Nemtsov (20):
wl12xx: Add AP related configuration to conf_drv_settings
wl12xx: AP mode - AP specific CMD_CONFIGURE sub-commands
wl12xx: AP mode - add AP specific event
wl12xx: AP-mode high level commands
wl12xx: AP mode - workaround for FW bug on station remove
wl12xx: AP mode - init sequence
wl12xx: AP specific RX filter configuration
wl12xx: Add AP related definitions to HOST-FW interface
wl12xx: Configure AP on BSS info change
wl12xx: AP mode config in ieee80211_ops.config
wl12xx: AP mode - change filter config
wl12xx: AP mode - add STA add/remove ops
wl12xx: AP mode - changes in TX path
wl12xx: AP mode - record TX configuration settings
wl12xx: AP mode - encryption support
wl12xx: AP mode - fetch appropriate firmware for AP
wl12xx: Read MAC address from NVS file on HW startup
wl12xx: Enable AP-mode
wl12xx: add missing MODULE_FIRMWARE statment for AP-mode FW
wl12xx: Add channel 14 to list of supported 2ghz channels
Ben Greear (1):
mac80211: Add sdata state and flags to debugfs.
Bob Copeland (4):
ath5k: fix error handling in ath5k_hw_dma_stop
ath5k: correct endianness of frame duration
ath5k: use tracing for packet tx/rx dump
ath5k: remove debug_dump_skb() functions
Bruno Randolf (5):
ath5k: Use local variable for capabilities
ath: Add function to check if 4.9GHz channels are allowed
ath5k: Enable 802.11j 4.9GHz frequencies
ath9k: Remove unused IEEE80211_WEP_NKID
ath5k: Fix short and long retry configuration
Chaoming Li (1):
rtlwifi: Fix firmware upload errors
Dan Carpenter (1):
wl12xx: use after free in debug code
Eliad Peller (6):
wl12xx: remove redundant debugfs_remove_recursive() call
wl12xx: fix some sparse warnings
wl12xx: don't join upon disassociation
wl12xx: fix some endianess bugs
wl12xx: wrong values are returned in gpio_power_write()
wl12xx: disable auto-arp
Felix Fietkau (8):
ath9k: clean up the code that wakes the mac80211 queues
ath9k: remove the virtual wiphy debugfs interface
ath9k: remove support for virtual wiphys
ath9k: remove the bf->aphy field
ath9k: fold struct ath_wiphy into struct ath_softc
ath9k: fix tx queue index confusion in debugfs code
ath9k: use split rx buffers to get rid of order-1 skb allocations
ath9k: fix compile error in non-debug ath_debug_stat_tx() stub
Gertjan van Wingerde (3):
rt2x00: Fix WPA TKIP Michael MIC failures.
rt2x00: Copy the MAC address to the WCID entry properly.
rt2x00: Fix FIXME comments in rt61pci and rt73usb on Michael MIC.
Guy Eilam (1):
wl12xx: change debug_level module param sysfs permissions
Helmut Schaa (13):
rt2x00: Refactor beacon code to make use of start- and stop_queue
rt2x00: Introduce beacon_update_locked that requires caller locking
rt2x00: Limit beacon updates in bss_info_changed to USB devices
rt2x00: Make periodic beacon updates for PCI devices atomic
rt2x00: Introduce tasklets for interrupt handling
rt2x00: Disable txstatus tasklet by default
rt2x00: Convert rt2800pci to use tasklets
rt2x00: Convert rt61pci to use tasklets
rt2x00: Convert rt2500pci interrupt handling to use tasklets
rt2x00: Convert rt2400pci interrupt handling to use tasklets
rt2x00: Remove interrupt thread registration
rt2x00: Remove STATE_RADIO_IRQ_OFF_ISR and STATE_RADIO_IRQ_ON_ISR
rt2x00: Update MAINTAINERS
Ivo van Doorn (2):
rt2x00: Kill all tasklets during device removal
rt2x00: Move TX/RX work into dedicated workqueue
Johannes Berg (1):
mac80211: add MCS information to radiotap
Johannes Stezenbach (1):
rt2x00: trivial: add \n to WARNING message
John W. Linville (3):
Merge branch 'for-linville' of git://git.kernel.org/.../luca/wl12xx
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Julia Lawall (1):
net/wireless/nl80211.c: Avoid call to genlmsg_cancel
Juuso Oikarinen (3):
wl12xx: Cleanup PLT mode when module is removed
wl12xx: Increase scan channel dwell time for passive scans
cfg80211: Allow non-zero indexes for device specific pair-wise ciphers
Levi, Shahar (2):
wl12xx: BA initiator support
wl12xx: BA receiver support
Luciano Coelho (6):
MAINTAINERS: update information for the wl12xx driver
wl12xx: don't modify the global supported band structures
wl12xx: lock the RCU when accessing sta via ieee80211_find_sta()
wl12xx: add hw configuration for max supported AMDPU size
MAINTAINERS: update information for the wl12xx driver
wl12xx: fix warning due to missing arg in ampdu_action
Mark Einon (1):
Trivial typo fix in comment
Mathias Krause (1):
wl12xx: fix use after free
Mohammed Shafi Shajakhan (1):
ath9k: Fix memory leak due to failed PAPRD frames
RA-Jay Hung (1):
rt2x00: Correct initial value of US_CYC_CNT register for pcie interface
Rajkumar Manoharan (4):
ath9k_hw: Fix system hang when resuming from S3/S4
ath9k: Fix power save usage count imbalance on deinit
ath9k: use common API to avoid code duplication
mac80211: disable power save if an infra AP vif exists
Stanislaw Gruszka (10):
ath9k: fix race conditions when stop device
ath9k_htc: fix race conditions when stop device
iwlwifi: do not set tx power when channel is changing
iwl3945: set STATUS_READY before commit_rxon
iwlwifi: remove unneeded __packed
iwlwifi: introduce iwl_advanced_bt_coexist()
iwlwifi: remove unneeded disable_hw_scan check
iwlwifi: introduce iwl_bt_statistics
iwl3945: do not use agn specific IWL_RATE_COUNT
iwlwifi: correct frequency settings
Sujith Manoharan (3):
ath9k_hw: Fix opmode initialization
ath9k_hw: Fix INI fixup
ath9k_hw: Add RX filters
Vivek Natarajan (5):
ath9k_hw: Add a function to read sqsum_dvc.
ath9k: Fix a PLL hang issue observed with AR9485.
ath9k_hw: DDR_PLL and BB_PLL need correct setting.
ath9k: Fix a locking related issue.
ath9k_hw: Update PMU setting to improve ripple issue for AR9485.
MAINTAINERS | 8 +-
drivers/bluetooth/ath3k.c | 75 +-
drivers/net/wireless/ath/ath5k/Kconfig | 11 +
drivers/net/wireless/ath/ath5k/ath5k.h | 18 +-
drivers/net/wireless/ath/ath5k/attach.c | 4 +-
drivers/net/wireless/ath/ath5k/base.c | 23 +-
drivers/net/wireless/ath/ath5k/caps.c | 48 +-
drivers/net/wireless/ath/ath5k/debug.c | 20 -
drivers/net/wireless/ath/ath5k/debug.h | 10 -
drivers/net/wireless/ath/ath5k/dma.c | 4 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 9 +
drivers/net/wireless/ath/ath5k/pcu.c | 4 +-
drivers/net/wireless/ath/ath5k/qcu.c | 46 +-
drivers/net/wireless/ath/ath5k/reg.h | 15 +-
drivers/net/wireless/ath/ath5k/trace.h | 107 ++
drivers/net/wireless/ath/ath9k/Makefile | 1 -
drivers/net/wireless/ath/ath9k/ahb.c | 13 +-
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 10 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 3 +-
.../net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 4 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 61 +-
drivers/net/wireless/ath/ath9k/beacon.c | 18 +-
drivers/net/wireless/ath/ath9k/common.h | 2 -
drivers/net/wireless/ath/ath9k/debug.c | 174 +---
drivers/net/wireless/ath/ath9k/debug.h | 5 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 6 +-
drivers/net/wireless/ath/ath9k/gpio.c | 3 +-
drivers/net/wireless/ath/ath9k/htc.h | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 -
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 21 +-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 8 +-
drivers/net/wireless/ath/ath9k/hw.c | 49 +-
drivers/net/wireless/ath/ath9k/hw.h | 2 +
drivers/net/wireless/ath/ath9k/init.c | 30 +-
drivers/net/wireless/ath/ath9k/mac.h | 2 +
drivers/net/wireless/ath/ath9k/main.c | 328 ++-----
drivers/net/wireless/ath/ath9k/pci.c | 20 +-
drivers/net/wireless/ath/ath9k/rc.c | 3 +-
drivers/net/wireless/ath/ath9k/recv.c | 155 ++--
drivers/net/wireless/ath/ath9k/reg.h | 17 +
drivers/net/wireless/ath/ath9k/virtual.c | 669 ------------
drivers/net/wireless/ath/ath9k/xmit.c | 138 ++--
drivers/net/wireless/ath/regd.c | 7 +
drivers/net/wireless/ath/regd.h | 1 +
drivers/net/wireless/iwlwifi/iwl-3945.c | 7 +-
drivers/net/wireless/iwlwifi/iwl-4965.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-agn-calib.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 12 +-
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 13 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.h | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-rx.c | 15 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 21 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 11 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-legacy.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-power.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 3 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 5 +-
drivers/net/wireless/iwmc3200wifi/netdev.c | 2 +
drivers/net/wireless/rt2x00/rt2400pci.c | 165 ++-
drivers/net/wireless/rt2x00/rt2500pci.c | 159 ++-
drivers/net/wireless/rt2x00/rt2500usb.c | 4 -
drivers/net/wireless/rt2x00/rt2800.h | 4 +
drivers/net/wireless/rt2x00/rt2800lib.c | 73 +-
drivers/net/wireless/rt2x00/rt2800lib.h | 1 +
drivers/net/wireless/rt2x00/rt2800pci.c | 192 +++--
drivers/net/wireless/rt2x00/rt2800usb.c | 9 +-
drivers/net/wireless/rt2x00/rt2x00.h | 35 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 69 +-
drivers/net/wireless/rt2x00/rt2x00firmware.c | 1 +
drivers/net/wireless/rt2x00/rt2x00lib.h | 24 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 7 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 44 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 7 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 60 +-
drivers/net/wireless/rt2x00/rt2x00reg.h | 2 -
drivers/net/wireless/rt2x00/rt2x00usb.c | 8 +-
drivers/net/wireless/rt2x00/rt61pci.c | 226 +++--
drivers/net/wireless/rt2x00/rt73usb.c | 50 +-
drivers/net/wireless/rtlwifi/efuse.c | 40 +-
drivers/net/wireless/rtlwifi/pci.c | 11 +-
drivers/net/wireless/wl12xx/acx.c | 160 +++-
drivers/net/wireless/wl12xx/acx.h | 91 ++-
drivers/net/wireless/wl12xx/boot.c | 35 +-
drivers/net/wireless/wl12xx/cmd.c | 308 ++++++-
drivers/net/wireless/wl12xx/cmd.h | 147 +++-
drivers/net/wireless/wl12xx/conf.h | 76 ++-
drivers/net/wireless/wl12xx/debugfs.c | 49 +-
drivers/net/wireless/wl12xx/event.c | 7 +-
drivers/net/wireless/wl12xx/event.h | 8 +-
drivers/net/wireless/wl12xx/init.c | 387 ++++++--
drivers/net/wireless/wl12xx/init.h | 2 +-
drivers/net/wireless/wl12xx/main.c | 1116 +++++++++++++++-----
drivers/net/wireless/wl12xx/rx.c | 14 +-
drivers/net/wireless/wl12xx/rx.h | 11 +-
drivers/net/wireless/wl12xx/sdio.c | 1 +
drivers/net/wireless/wl12xx/spi.c | 3 +-
drivers/net/wireless/wl12xx/tx.c | 105 ++-
drivers/net/wireless/wl12xx/tx.h | 10 +-
drivers/net/wireless/wl12xx/wl12xx.h | 88 ++-
drivers/net/wireless/wl12xx/wl12xx_80211.h | 11 +-
include/linux/ieee80211.h | 2 +-
include/net/bluetooth/hci_core.h | 1 +
include/net/ieee80211_radiotap.h | 25 +
net/bluetooth/hci_conn.c | 16 +-
net/bluetooth/hci_core.c | 4 +
net/bluetooth/hci_event.c | 9 +-
net/bluetooth/l2cap.c | 84 +-
net/bluetooth/rfcomm/core.c | 3 +-
net/mac80211/agg-rx.c | 11 +-
net/mac80211/debugfs_netdev.c | 14 +
net/mac80211/main.c | 12 +-
net/mac80211/mlme.c | 8 +
net/mac80211/rx.c | 17 +
net/mac80211/tx.c | 3 +
net/wireless/nl80211.c | 6 +-
net/wireless/util.c | 11 +-
122 files changed, 3801 insertions(+), 2533 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath5k/trace.h
delete mode 100644 drivers/net/wireless/ath/ath9k/virtual.c
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2011-02-02.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: Tree for February 1 (ip_vs)
From: Simon Horman @ 2011-02-02 22:31 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, netdev, linux-next, LKML
In-Reply-To: <20110201091620.64536300.randy.dunlap@oracle.com>
On Tue, Feb 01, 2011 at 09:16:20AM -0800, Randy Dunlap wrote:
> On Tue, 1 Feb 2011 15:34:03 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since 20110131:
>
>
> When CONFIG_IP_VS_PROTO_TCP is not set:
>
> net/netfilter/ipvs/ip_vs_proto_sctp.c:1104: error: 'struct netns_ipvs' has no member named 'tcp_app_lock'
> net/netfilter/ipvs/ip_vs_proto_sctp.c:1104: error: 'struct netns_ipvs' has no member named 'tcp_app_lock'
Thanks, the following patch should resolve this problem.
Hans, could you verify this change?
The change is available at
git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git master
From: Simon Horman <horms@verge.net.au>
IPVS: Use correct lock in SCTP module
Use sctp_app_lock instead of tcp_app_lock in the SCTP protocol module.
This appears to be a typo introduced by the netns changes.
Cc: Hans Schillstrom <hans@schillstrom.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_proto_sctp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c b/net/netfilter/ipvs/ip_vs_proto_sctp.c
index fb2d04a..b027ccc 100644
--- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
@@ -1101,7 +1101,7 @@ static void __ip_vs_sctp_init(struct net *net, struct ip_vs_proto_data *pd)
struct netns_ipvs *ipvs = net_ipvs(net);
ip_vs_init_hash_table(ipvs->sctp_apps, SCTP_APP_TAB_SIZE);
- spin_lock_init(&ipvs->tcp_app_lock);
+ spin_lock_init(&ipvs->sctp_app_lock);
pd->timeout_table = ip_vs_create_timeout_table((int *)sctp_timeouts,
sizeof(sctp_timeouts));
}
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH net-2.6] gro: reset skb_iif on reuse
From: David Miller @ 2011-02-02 22:53 UTC (permalink / raw)
To: andy; +Cc: netdev
In-Reply-To: <1296682047-15885-1-git-send-email-andy@greyhouse.net>
From: andy@greyhouse.net
Date: Wed, 2 Feb 2011 16:27:27 -0500
> Like Herbert's change from a few days ago:
>
> 66c46d741e2e60f0e8b625b80edb0ab820c46d7a gro: Reset dev pointer on reuse
>
> this may not be necessary at this point, but we should still clean up
> the skb->skb_iif. If not we may end up with an invalid valid for
> skb->skb_iif when the skb is reused and the check is done in
> __netif_receive_skb.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Applied, thanks Andy.
^ permalink raw reply
* Re: [PATCH] be2net: use device model DMA API
From: David Miller @ 2011-02-02 22:57 UTC (permalink / raw)
To: ivecera; +Cc: netdev, sathyap, subbus, sarveshwarb, ajitk
In-Reply-To: <1296669912-26563-1-git-send-email-ivecera@redhat.com>
From: Ivan Vecera <ivecera@redhat.com>
Date: Wed, 2 Feb 2011 19:05:12 +0100
> Use DMA API as PCI equivalents will be deprecated.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Looks good to me, can I get some review from the be2net maintainers?
^ permalink raw reply
* Re: [patch 0/6] [resend] s390: network patches for net-next
From: David Miller @ 2011-02-02 23:01 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20110202160430.554090958@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Wed, 02 Feb 2011 17:04:30 +0100
> Hi Dave,
>
> I have removed the NET_SKB_PAD patch from the patch set.
> We will define it in an arch specific header. The new
> version of the patch will come via the s390 tree. Thx!
All applied, thanks Frank.
^ permalink raw reply
* Re: [PATCH v4 0/2] iproute2: support for device groups
From: Patrick McHardy @ 2011-02-02 23:01 UTC (permalink / raw)
To: Vlad Dogaru; +Cc: netdev, Stephen Hemminger
In-Reply-To: <1296671021-24421-1-git-send-email-ddvlad@rosedu.org>
Am 02.02.2011 19:23, schrieb Vlad Dogaru:
> This patch series adds userspace support for network device groups.
> There is support for setting device groups, listing only interfaces of a
> specific group, and setting basic device parameters for all interfaces
> in a group.
>
> Changes since version 3:
> * drop devgroup keyword. There is a single keyword for specifying
> groups now.
> * store group names internally as a hash, similar to routing table
> names. This is more efficient for batch mode operations
Looks good to me, thanks.
^ permalink raw reply
* Re: [Patch] atl1c: Add missing PCI device ID
From: David Miller @ 2011-02-02 23:02 UTC (permalink / raw)
To: cebbert; +Cc: netdev, Jie.Yang
In-Reply-To: <20110202105902.3c0d2f9e@katamari>
From: Chuck Ebbert <cebbert@redhat.com>
Date: Wed, 2 Feb 2011 10:59:02 -0500
>
> Commit 8f574b35f22fbb9b5e5f1d11ad6b55b6f35f4533 added support for a new
> adapter but failed to add it to the PCI device table.
>
> Signed-Off-By: Chuck Ebbert <cebbert@redhat.com>
Applied, thanks Chuck.
^ permalink raw reply
* 2.6.38-rc3-git1: Reported regressions from 2.6.37
From: Rafael J. Wysocki @ 2011-02-02 23:02 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.37,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.37, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2011-02-03 19 11 7
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28102
Subject : New display errors in 2.6.38-rc2-00175-g6fb1b30
Submitter : Nico Schottelius <nico-kernel-20110117@schottelius.org>
Date : 2011-01-28 20:29 (6 days old)
Message-ID : <20110128202905.GB3395@schottelius.org>
References : http://marc.info/?l=linux-kernel&m=129624657425949&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28052
Subject : [BUG] 2.6.38-rc2: Circular Locking Dependency
Submitter : Knut Petersen <Knut_Petersen@t-online.de>
Date : 2011-01-24 9:25 (10 days old)
Message-ID : <4D3D45A3.7040809@t-online.de>
References : http://marc.info/?l=linux-kernel&m=129586118515443&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27812
Subject : 2.6.38-rc2: acpi backlight control missing
Submitter : Thomas Meyer <thomas@m3y3r.de>
Date : 2011-01-22 10:49 (12 days old)
First-Bad-Commit: http://git.kernel.org/linus/677bd810eedce61edf15452491781ff046b92edc
Message-ID : <1295693349.2120.3.camel@localhost.localdomain>
References : http://marc.info/?l=linux-kernel&m=129569353414755&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27652
Subject : 38-rc1: umount+rmmod cause ext4 error.
Submitter : Tao Ma <tm@tao.ma>
Date : 2011-01-19 6:53 (15 days old)
Message-ID : <4D368A70.5030103@tao.ma>
References : http://marc.info/?l=linux-ext4&m=129542001031750&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27382
Subject : ath5k phy0: gain calibration timeout
Submitter : Nicolas Stransky <Nico@stransky.cx>
Date : 2011-01-23 00:18 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27282
Subject : Regression: 2.6.38 vs. Powertop 2
Submitter : Dennis Jansen <dennis.jansen@web.de>
Date : 2011-01-21 14:34 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27022
Subject : [REPORT] BUG: spinlock recursion on CPU#0, init/1
Submitter : Santosh Shilimkar <santosh.shilimkar@ti.com>
Date : 2011-01-10 15:33 (24 days old)
Message-ID : <a7a9bdaa5936630925fb7ffd1a1795b1@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129467294808655&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28012
Subject : [drm:i915_driver_load] *ERROR* failed to init modeset, EINVAL
Submitter : Ferenc Wágner <wferi@niif.hu>
Date : 2011-02-01 15:18 (2 days old)
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=45892
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27862
Subject : Cannot launch X.org server on Core I5 with 2.6.38-rc2-git7
Submitter : Darisuz Luksza <dariusz.luksza@gmail.com>
Date : 2011-01-30 12:13 (4 days old)
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Patch : https://bugs.freedesktop.org/attachment.cgi?id=42634
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27702
Subject : regression 2.6.37 -> 2.6.38-rc1: after suspend backlight cannot be adjusted
Submitter : Norbert Preining <preining@logic.at>
Date : 2011-01-21 1:55 (13 days old)
Message-ID : <20110121015529.GD9796@gamma.logic.tuwien.ac.at>
References : http://marc.info/?l=linux-kernel&m=129557717826819&w=2
Handled-By : Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Patch : https://patchwork.kernel.org/patch/499221/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27472
Subject : 5bd5a45 breaks resume from suspend on Thinkpad X201
Submitter : Björn Schließmann <chronoss@gmx.de>
Date : 2011-01-23 23:24 (11 days old)
Handled-By : CASTET Matthieu <castet.matthieu@free.fr>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=45192
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.37,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=27352
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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] bna: use device model DMA API
From: David Miller @ 2011-02-02 23:03 UTC (permalink / raw)
To: ivecera; +Cc: netdev, rmody, ddutt
In-Reply-To: <1296657422-13537-1-git-send-email-ivecera@redhat.com>
From: Ivan Vecera <ivecera@redhat.com>
Date: Wed, 2 Feb 2011 15:37:02 +0100
> Use DMA API as PCI equivalents will be deprecated.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Looks good to me, can we get some review from the BNA maintainers
please?
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] IPVS build fixes and clean-ups
From: Patrick McHardy @ 2011-02-02 23:02 UTC (permalink / raw)
To: Simon Horman
Cc: Randy Dunlap, netdev, linux-next, linux-kernel, lvs-devel,
Stephen Rothwell, Hans Schillstrom
In-Reply-To: <20110202213907.GI2248@verge.net.au>
Am 02.02.2011 22:39, schrieb Simon Horman:
> On Tue, Feb 01, 2011 at 06:19:56PM +0100, Patrick McHardy wrote:
>> Thanks, since Simon is travelling, I'll apply the patches now
>> with your and Hans's Acks and will push them to Dave later.
>
> Thanks, I've finished travelling now :-)
>
The patches got delayed a bit due to a build error in nf-next,
but I'll send them to Dave shortly.
^ 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