* Adding bridge interface to non-default network namespace crashes kernel
From: Atis Elsts @ 2009-09-07 15:07 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: containers-qjLDD68F18O7TbgM5vRIOg
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
Trying to add bridge interface from userspace program, after moving the
program to a new network namespace, causes kernel to crash. I am using latest
kernel version from git (2.6.31-rc9).
The bug is easy to reproduce - just compile and run the attached C program.
I see that bridge interface has NETIF_F_NETNS_LOCAL flag, but as I understand,
this flag simply means that a device cannot be *moved* across network
namespaces, not that it cannot be *created* in other namespaces.
--Atis
[-- Attachment #2: crash.c --]
[-- Type: text/x-csrc, Size: 571 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <linux/sched.h>
#include <linux/sockios.h>
int main() {
if (unshare(CLONE_NEWNET)) {
perror("unshare");
return -1;
}
int fd = socket(AF_INET, SOCK_DGRAM, 0);
if (fd < 0) {
perror("socket");
return -1;
}
const char *name = "lobridge";
if (ioctl(fd, SIOCBRADDBR, name) < 0) {
perror("ioctl SIOCBRADDBR");
return -1;
}
system("ip addr");
for (;;) {
printf("still running\n");
sleep(5);
}
}
[-- Attachment #3: syslog --]
[-- Type: text/plain, Size: 3289 bytes --]
Sep 7 16:06:19 debian kernel: [ 91.040000] ------------[ cut here ]------------
Sep 7 16:06:19 debian kernel: [ 91.040000] kernel BUG at fs/sysfs/group.c:65!
Sep 7 16:06:19 debian kernel: [ 91.040000] invalid opcode: 0000 [#1] SMP
Sep 7 16:06:19 debian kernel: [ 91.040000] last sysfs file: /sys/devices/virtual/net/lo/operstate
Sep 7 16:06:19 debian kernel: [ 91.040000] Modules linked in:
Sep 7 16:06:19 debian kernel: [ 91.040000]
Sep 7 16:06:19 debian kernel: [ 91.040000] Pid: 1667, comm: a.out Not tainted (2.6.31-rc9 #16)
Sep 7 16:06:19 debian kernel: [ 91.040000] EIP: 0060:[<c0218c5e>] EFLAGS: 00000246 CPU: 0
Sep 7 16:06:19 debian kernel: [ 91.040000] EIP is at internal_create_group+0x14e/0x180
Sep 7 16:06:19 debian kernel: [ 91.040000] EAX: 00000000 EBX: c71fb000 ECX: c053aae0 EDX: 00000000
Sep 7 16:06:19 debian kernel: [ 91.040000] ESI: 00000000 EDI: c71fb25c EBP: c6dede58 ESP: c6dede30
Sep 7 16:06:19 debian kernel: [ 91.040000] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Sep 7 16:06:19 debian kernel: [ 91.040000] Process a.out (pid: 1667, ti=c6dec000 task=c6df1920 task.ti=c6dec000)
Sep 7 16:06:19 debian kernel: [ 91.040000] Stack:
Sep 7 16:06:19 debian kernel: [ 91.040000] c71fb008 c053aae0 00000000 c71fb25c 00000000 00000000 c6dede58 c71fb000
Sep 7 16:06:19 debian kernel: [ 91.040000] <0> 00000000 c71fb25c c6dede60 c0218cbc c6dede84 c03c6bc3 00000000 00000000
Sep 7 16:06:19 debian kernel: [ 91.040000] <0> 00000000 c7102000 c71fb000 00000000 c7102000 c6dedea0 c03c348f 00000001
Sep 7 16:06:19 debian kernel: [ 91.040000] Call Trace:
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c0218cbc>] ? sysfs_create_group+0xc/0x10
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c03c6bc3>] ? br_sysfs_addbr+0x23/0xf0
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c03c348f>] ? br_add_bridge+0x18f/0x1a0
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c03c4328>] ? br_ioctl_deviceless_stub+0x1f8/0x210
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c03c4130>] ? br_ioctl_deviceless_stub+0x0/0x210
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c032e0cf>] ? sock_ioctl+0xbf/0x220
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c032e010>] ? sock_ioctl+0x0/0x220
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c01d4e28>] ? vfs_ioctl+0x28/0x80
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c01d4faa>] ? do_vfs_ioctl+0x6a/0x520
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c032d2a3>] ? sock_map_fd+0x43/0x70
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c032db22>] ? sys_socket+0x52/0x70
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c0118138>] ? do_page_fault+0x168/0x310
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c01d54b3>] ? sys_ioctl+0x53/0x70
Sep 7 16:06:19 debian kernel: [ 91.040000] [<c0102c04>] ? sysenter_do_call+0x12/0x22
Sep 7 16:06:19 debian kernel: [ 91.040000] Code: bd 8b 5d e0 83 45 ec 01 85 db 0f 84 63 ff ff ff 8b 12 89 f8 e8 e4 ce ff ff 8b 16 e9 53 ff ff ff 8b 40 18 85 c0 0f 85 e9 fe ff ff <0f> 0b eb fe 89 f8 e8 47 ea ff ff 8b 45 e8 83 c4 1c 5b 5e 5f 5d
Sep 7 16:06:19 debian kernel: [ 91.040000] EIP: [<c0218c5e>] internal_create_group+0x14e/0x180 SS:ESP 0068:c6dede30
Sep 7 16:06:19 debian kernel: [ 91.040000] ---[ end trace beadcfdb06c985eb ]---
[-- Attachment #4: Type: text/plain, Size: 206 bytes --]
_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers
^ permalink raw reply
* [PATCH -next] cdc_ether: additional Ericsson MBM PID's to the whitelist
From: Torgny Johansson @ 2009-09-07 14:36 UTC (permalink / raw)
To: David Brownell; +Cc: netdev
This is a re-submit since I did not see any feedback on the first submittal.
This patch adds seven PID's to the whitelist set of devices.
Devices added to the whitelist:
Ericsson Mobile Broadband Module variants (F3607gw and F3307)
Dell F3607gw variants
Toshiba F3607gw variants
Signed-off-by: Torgny Johansson <torgny.johansson@ericsson.com>
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index c47237c..32d9356 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -174,7 +174,7 @@ config USB_NET_CDCETHER
* Ericsson Mobile Broadband Module (all variants)
* Motorola (DM100 and SB4100)
* Broadcom Cable Modem (reference design)
- * Toshiba (PCX1100U and F3507g)
+ * Toshiba (PCX1100U and F3507g/F3607gw)
* ...
This driver creates an interface named "ethX", where X depends on diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c index 4a6aff5..5d99106 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -544,20 +544,55 @@ static const struct usb_device_id products [] = {
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info, }, {
- /* Ericsson F3307 */
+ /* Ericsson F3607gw ver 2 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0bdb, 0x1905, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info, }, {
+ /* Ericsson F3607gw ver 3 */
USB_DEVICE_AND_INTERFACE_INFO(0x0bdb, 0x1906, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info, }, {
+ /* Ericsson F3307 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0bdb, 0x190a, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info, }, {
+ /* Ericsson F3307 ver 2 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0bdb, 0x1909, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info, }, {
/* Toshiba F3507g */
USB_DEVICE_AND_INTERFACE_INFO(0x0930, 0x130b, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info, }, {
+ /* Toshiba F3607gw */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0930, 0x130c, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info, }, {
+ /* Toshiba F3607gw ver 2 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0930, 0x1311, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info, }, {
/* Dell F3507g */
USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x8147, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,
+}, {
+ /* Dell F3607gw */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x8183, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info, }, {
+ /* Dell F3607gw ver 2 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x8184, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info,
},
{ }, // END
};
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Daniel Walker @ 2009-09-07 14:30 UTC (permalink / raw)
To: Tilman Schmidt; +Cc: davem, linux-kernel, netdev, i4ldeveloper, Hansjoerg Lipp
In-Reply-To: <4AA4CD64.4070501@imap.cc>
On Mon, 2009-09-07 at 11:07 +0200, Tilman Schmidt wrote:
> Daniel,
>
> thanks for taking a look at my patches.
>
> On Sun, 06 Sep 2009 18:26:46 -0700, Daniel Walker wrote:
> > patches 6,7,10, and 12 all have checkpatch errors. Could you fix those?
>
> I have reissued patch 7, exchanging the "static" and "inline" keywords
> as requested.
>
> The other patches I'd much prefer to keep as they are. The "ERRORs"
> checkpatch.pl reported for them are results of keeping to the existing
> formatting of the patched files. Completely reformatting them would
> cloud the actual changes made by the patches.
Yeah, it looks like the whole file needs a checkpatch clean up.. Sounds
like your not willing to do that? Usually if a checkpatch cleanup comes
first prior to all your other changes , it doesn't usually cloud the
rest of the changes..
Daniel
^ permalink raw reply
* Re: net_sched 00/07: classful multiqueue dummy scheduler
From: Patrick McHardy @ 2009-09-07 14:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <4AA50ACF.9010400@trash.net>
[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]
Patrick McHardy wrote:
> Eric Dumazet wrote:
>> Had very litle time to test this, but got problems very fast, if rate estimator configured.
>
> I didn't test that, but I'll look into it.
>
>> qdisc mq 1: root
>> Sent 528702 bytes 3491 pkt (dropped 0, overlimits 0 requeues 0)
>> rate 177925Kbit 49pps backlog 0b 0p requeues 0
>> qdisc pfifo 8001: parent 1:1 limit 1000p
>> Sent 528702 bytes 3491 pkt (dropped 0, overlimits 0 requeues 0)
>> rate 25400bit 21pps backlog 0b 0p requeues 0
>>
>> <<<crash>>>
>
> Did you capture the crash?
>
>> (On another term I had a "ping -i 0.1 192.168.20.120" that gave :
>>
>> 2009/08/07 14:53:42.498 64 bytes from 192.168.20.120: icmp_seq=1982 ttl=64 time=0.126 ms
>> 2009/08/07 14:53:42.598 64 bytes from 192.168.20.120: icmp_seq=1983 ttl=64 time=0.118 ms
>> 2009/08/07 14:53:42.698 64 bytes from 192.168.20.120: icmp_seq=1984 ttl=64 time=0.114 ms
>> 2009/08/07 14:53:42.798 64 bytes from 192.168.20.120: icmp_seq=1985 ttl=64 time=0.123 ms
>> 2009/08/07 14:53:42.898 64 bytes from 192.168.20.120: icmp_seq=1986 ttl=64 time=0.126 ms
>> 2009/08/07 14:53:42.998 64 bytes from 192.168.20.120: icmp_seq=1987 ttl=64 time=0.119 ms
>> 2009/08/07 14:53:43.098 64 bytes from 192.168.20.120: icmp_seq=1988 ttl=64 time=0.122 ms
>> 2009/08/07 14:53:43.198 64 bytes from 192.168.20.120: icmp_seq=1989 ttl=64 time=0.119 ms
>> 2009/08/07 14:53:43.298 64 bytes from 192.168.20.120: icmp_seq=1990 ttl=64 time=0.117 ms
>> 2009/08/07 14:53:43.398 64 bytes from 192.168.20.120: icmp_seq=1991 ttl=64 time=0.117 ms
>> ping: sendmsg: No buffer space available
>
> Was this also with rate estimators? No buffer space available
> indicates that some class/qdisc isn't dequeued or the packets
> are leaking, so the output of tc -s -d qdisc show ... might be
> helpful.
I figured out the bug, which is likely responsible for both
problems. When grafting a mq class and creating a rate estimator,
the new qdisc is not attached to the device queue yet and also
doesn't have TC_H_ROOT as parent, so qdisc_create() selects
qdisc_root_sleeping_lock() for the estimator, which belongs to
the qdisc that is getting replaced.
This is a patch I used for testing, but I'll come up with
something more elegant (I hope) as a final fix :)
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1497 bytes --]
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 2a78d54..428eb34 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -732,7 +732,8 @@ static struct lock_class_key qdisc_rx_lock;
*/
static struct Qdisc *
-qdisc_create(struct net_device *dev, struct netdev_queue *dev_queue,
+qdisc_create(struct net_device *dev, struct Qdisc *p,
+ struct netdev_queue *dev_queue,
u32 parent, u32 handle, struct nlattr **tca, int *errp)
{
int err;
@@ -810,8 +811,9 @@ qdisc_create(struct net_device *dev, struct netdev_queue *dev_queue,
if (tca[TCA_RATE]) {
spinlock_t *root_lock;
- if ((sch->parent != TC_H_ROOT) &&
- !(sch->flags & TCQ_F_INGRESS))
+ if (((sch->parent != TC_H_ROOT) &&
+ !(sch->flags & TCQ_F_INGRESS)) &&
+ (!p || !p->ops->attach))
root_lock = qdisc_root_sleeping_lock(sch);
else
root_lock = qdisc_lock(sch);
@@ -1097,7 +1099,7 @@ create_n_graft:
if (!(n->nlmsg_flags&NLM_F_CREATE))
return -ENOENT;
if (clid == TC_H_INGRESS)
- q = qdisc_create(dev, &dev->rx_queue,
+ q = qdisc_create(dev, p, &dev->rx_queue,
tcm->tcm_parent, tcm->tcm_parent,
tca, &err);
else {
@@ -1106,7 +1108,7 @@ create_n_graft:
if (p && p->ops->cl_ops && p->ops->cl_ops->select_queue)
ntx = p->ops->cl_ops->select_queue(p, tcm);
- q = qdisc_create(dev, netdev_get_tx_queue(dev, ntx),
+ q = qdisc_create(dev, p, netdev_get_tx_queue(dev, ntx),
tcm->tcm_parent, tcm->tcm_handle,
tca, &err);
}
^ permalink raw reply related
* Re: net_sched 00/07: classful multiqueue dummy scheduler
From: Patrick McHardy @ 2009-09-07 13:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <4AA503E4.2060504@gmail.com>
Eric Dumazet wrote:
> David Miller a écrit :
>> I gave these patches a very basic bashing with NIU, and it
>> seems to work from what I've tried.
>>
>> I know that Jarek has expressed some questions about the callback
>> scheme used by the new mq classful qdisc, as well as some other
>> issues, but we can refine this using followon patches.
>>
>> For now I'm pushing this out so that it gets wider testing.
>>
>> Thanks everyone!
>
> Very interesting :)
>
> Had very litle time to test this, but got problems very fast, if rate estimator configured.
I didn't test that, but I'll look into it.
> qdisc mq 1: root
> Sent 528702 bytes 3491 pkt (dropped 0, overlimits 0 requeues 0)
> rate 177925Kbit 49pps backlog 0b 0p requeues 0
> qdisc pfifo 8001: parent 1:1 limit 1000p
> Sent 528702 bytes 3491 pkt (dropped 0, overlimits 0 requeues 0)
> rate 25400bit 21pps backlog 0b 0p requeues 0
>
> <<<crash>>>
Did you capture the crash?
> (On another term I had a "ping -i 0.1 192.168.20.120" that gave :
>
> 2009/08/07 14:53:42.498 64 bytes from 192.168.20.120: icmp_seq=1982 ttl=64 time=0.126 ms
> 2009/08/07 14:53:42.598 64 bytes from 192.168.20.120: icmp_seq=1983 ttl=64 time=0.118 ms
> 2009/08/07 14:53:42.698 64 bytes from 192.168.20.120: icmp_seq=1984 ttl=64 time=0.114 ms
> 2009/08/07 14:53:42.798 64 bytes from 192.168.20.120: icmp_seq=1985 ttl=64 time=0.123 ms
> 2009/08/07 14:53:42.898 64 bytes from 192.168.20.120: icmp_seq=1986 ttl=64 time=0.126 ms
> 2009/08/07 14:53:42.998 64 bytes from 192.168.20.120: icmp_seq=1987 ttl=64 time=0.119 ms
> 2009/08/07 14:53:43.098 64 bytes from 192.168.20.120: icmp_seq=1988 ttl=64 time=0.122 ms
> 2009/08/07 14:53:43.198 64 bytes from 192.168.20.120: icmp_seq=1989 ttl=64 time=0.119 ms
> 2009/08/07 14:53:43.298 64 bytes from 192.168.20.120: icmp_seq=1990 ttl=64 time=0.117 ms
> 2009/08/07 14:53:43.398 64 bytes from 192.168.20.120: icmp_seq=1991 ttl=64 time=0.117 ms
> ping: sendmsg: No buffer space available
Was this also with rate estimators? No buffer space available
indicates that some class/qdisc isn't dequeued or the packets
are leaking, so the output of tc -s -d qdisc show ... might be
helpful.
^ permalink raw reply
* Re: net_sched 07/07: add classful multiqueue dummy scheduler
From: Patrick McHardy @ 2009-09-07 13:27 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20090906200409.GB8833@ami.dom.local>
Jarek Poplawski wrote:
>> struct Qdisc_class_ops
>> {
>> /* Child qdisc manipulation */
>> + unsigned int (*select_queue)(struct Qdisc *, struct tcmsg *);
>> int (*graft)(struct Qdisc *, unsigned long cl,
>> struct Qdisc *, struct Qdisc **);
>> struct Qdisc * (*leaf)(struct Qdisc *, unsigned long cl);
>> @@ -122,6 +123,7 @@ struct Qdisc_ops
>> void (*reset)(struct Qdisc *);
>> void (*destroy)(struct Qdisc *);
>> int (*change)(struct Qdisc *, struct nlattr *arg);
>> + void (*attach)(struct Qdisc *);
>
> Probably it's a matter of taste, but I wonder why these two methods
> used only by one qdisc in max 2 places can't be functions instead
> (maybe even static in case of select_queue)? (And this mq sched could
> be tested with some flag instead of ->attach, I guess.)
Yes, we could also use normal functions. Either way is fine with me.
>> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>> index d71f12b..2a78d54 100644
>> --- a/net/sched/sch_api.c
>> +++ b/net/sched/sch_api.c
>> @@ -678,6 +678,11 @@ static int qdisc_graft(struct net_device *dev, struct Qdisc *parent,
>> if (dev->flags & IFF_UP)
>> dev_deactivate(dev);
>>
>> + if (new && new->ops->attach) {
>> + new->ops->attach(new);
>> + num_q = 0;
>> + }
>> +
>
> Actually, I wonder if it's not cleaner to let replace all qdiscs with
> noops below like in qdisc delete case, and do this attaching in one
> place only (dev_activate).
I don't think that would work since dev_activate() allocates its own
qdiscs, which use different handles than those specified by userspace.
We also need the new qdisc for notifications. It would be a nice
cleanup however if you can make it work.
>> @@ -1095,10 +1100,16 @@ create_n_graft:
>> q = qdisc_create(dev, &dev->rx_queue,
>> tcm->tcm_parent, tcm->tcm_parent,
>> tca, &err);
>> - else
>> - q = qdisc_create(dev, netdev_get_tx_queue(dev, 0),
>> + else {
>> + unsigned int ntx = 0;
>> +
>> + if (p && p->ops->cl_ops && p->ops->cl_ops->select_queue)
>> + ntx = p->ops->cl_ops->select_queue(p, tcm);
>
> So, this if could be probably made shorter with a common function, but
> the main point is: this probably works only for qdiscs having mq as a
> parent, and not below.
Yes. mq can only be attached to the root however, so its not
possible to use it as a child qdisc.
>> +static int mq_init(struct Qdisc *sch, struct nlattr *opt)
>> +{
>> + struct net_device *dev = qdisc_dev(sch);
>> + struct mq_sched *priv = qdisc_priv(sch);
>> + struct netdev_queue *dev_queue;
>> + struct Qdisc *qdisc;
>> + unsigned int ntx;
>> +
>> + if (sch->parent != TC_H_ROOT)
>> + return -EOPNOTSUPP;
>> +
>> + if (!netif_is_multiqueue(dev))
>> + return -EOPNOTSUPP;
>> +
>> + /* pre-allocate qdiscs, attachment can't fail */
>> + priv->qdiscs = kcalloc(dev->num_tx_queues, sizeof(priv->qdiscs[0]),
>> + GFP_KERNEL);
>
> I guess we could avoid this at all or at least to do it in one step with
> current ->attach.
It seemed easier this way, but I don't care much where its done exactly.
>> + if (priv->qdiscs == NULL)
>> + return -ENOMEM;
>> +
>> + for (ntx = 0; ntx < dev->num_tx_queues; ntx++) {
>> + dev_queue = netdev_get_tx_queue(dev, ntx);
>> + qdisc = qdisc_create_dflt(dev, dev_queue, &pfifo_fast_ops,
>> + TC_H_MAKE(TC_H_MAJ(sch->handle),
>> + TC_H_MIN(ntx + 1)));
>
> As I wrote in 05/07 comment, I wonder if we really can't achieve this
> with old TC_H_ROOT parentid, and maybe some mapping while dumping to
> the userspace only.
I don't see the advantage.
> Another possibility would be considering a new
> kind of root (mqroot?) to tell precisely, where a new qdisc should be
> added.
That's what mq is doing.
>> +static int mq_dump(struct Qdisc *sch, struct sk_buff *skb)
>> +{
>> + struct net_device *dev = qdisc_dev(sch);
>> + struct Qdisc *qdisc;
>> + unsigned int ntx;
>> +
>> + sch->q.qlen = 0;
>> + memset(&sch->bstats, 0, sizeof(sch->bstats));
>> + memset(&sch->qstats, 0, sizeof(sch->qstats));
>> +
>> + for (ntx = 0; ntx < dev->num_tx_queues; ntx++) {
>> + qdisc = netdev_get_tx_queue(dev, ntx)->qdisc_sleeping;
>> + spin_lock_bh(qdisc_lock(qdisc));
>> + sch->q.qlen += qdisc->q.qlen;
>> + sch->bstats.bytes += qdisc->bstats.bytes;
>> + sch->bstats.packets += qdisc->bstats.packets;
>> + sch->qstats.qlen += qdisc->qstats.qlen;
>
> Like in Christoph's case, we should probably use q.qlen instead.
Its done a few lines above. This simply sums up all members of qstats.
^ permalink raw reply
* Re: [PATCH 1/2] Add an alternative cs89x0 driver
From: Sascha Hauer @ 2009-09-07 13:21 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: netdev
In-Reply-To: <20090907123554.GA2928@e-circ.dyndns.org>
On Mon, Sep 07, 2009 at 02:35:54PM +0200, Kurt Van Dijck wrote:
> On Mon, Sep 07, 2009 at 12:24:34PM +0200, Sascha Hauer wrote:
> > Date: Mon, 7 Sep 2009 12:24:34 +0200
> > Subject: Re: [PATCH 1/2] Add an alternative cs89x0 driver
> > From: Sascha Hauer <s.hauer@pengutronix.de>
> > To: Kurt Van Dijck <kurt.van.dijck@eia.be>
> > Cc: netdev@vger.kernel.org
> > List-ID: <netdev.vger.kernel.org>
> >
> > Hi Kurt,
> >
> > On Wed, Aug 26, 2009 at 12:46:34PM +0200, Kurt Van Dijck wrote:
> > > Hi Sacha,
> > >
> > > I'm using a 2.6.25.
> > > Converting to your platform_device based driver,
> > > I needed to configure the irq (see patch, irq flags).
> > > Looking in the old cs89x0.c, it's done in the driver. Should I have
> > > configured the irq level elsewhere? Or is this patch valid to do?
> >
> > This is the way to go. I don't know if the cs89x0 has configurable
> > interrupt levels though.
> I haven't read any spec about cs89x0, but by looking in the existing
> code:
> 1) IRQF_TRIGGER_HIGH seems like the default
> 2) the old driver didn't do any irq config in the chip either.
> May I assume you were lucky testing the driver on a platform that had
> IRQF_TRIGGER_HIGH per default?
> I have it running (with patch) on a iMX31 (arm)
I tested it with an i.MX1. Looking at the code it seems that
__irq_set_trigger is only called if one of the trigger mask bits is set.
So the interrupt control registers are never touched when 0 is passed as
irq flags. The reset default for i.MX is rising edge.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: net_sched 05/07: reintroduce dev->qdisc for use by sch_api
From: Patrick McHardy @ 2009-09-07 13:16 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20090906185757.GA8833@ami.dom.local>
Jarek Poplawski wrote:
>> @@ -1383,7 +1375,7 @@ static int tc_ctl_tclass(struct sk_buff *skb, struct nlmsghdr *n, void *arg)
>> pid = TC_H_MAKE(qid, pid);
>> } else {
>> if (qid == 0)
>> - qid = dev_queue->qdisc_sleeping->handle;
>> + qid = dev->qdisc->handle;
>
> Probably I miss something, but in mq root case it seems to never do
> anything we need. If so, it could be the example of possible issues
> elsewhere.
Sorry, I'm not sure what you're saying ..
> I thought this mq virtual root qdisc could be done more transparently
> and invisible for the current code, but it seems, in your
> implementation some pointers like this, or parent ids (especially
> TC_H_ROOT) might be different, and even if it works OK, needs a lot of
> verification. So, my question is, if it's really necessary.
Same here.
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: jamal @ 2009-09-07 12:54 UTC (permalink / raw)
To: Xiaofei Wu; +Cc: linux netdev
In-Reply-To: <749852.6581.qm@web111606.mail.gq1.yahoo.com>
On Mon, 2009-09-07 at 05:38 -0700, Xiaofei Wu wrote:
> I just want to know:
> 1) Could I forward the mirroring packets to another node ,and then route it to the destination(if I use
> iproute2 (ip, tc ...) )? I described my purpose in my last email.
Yes, you can mirror to another node(B/D). To route on that node(B/D),
your dst MAC address has to be correct for that destination node(B/D) to
accept it. You could try to run the destination node in promisc mode
and you may be able to get away without changing dst mac.
> 2) After I mirrored the packets, I should use 'ip route' , 'ip rule' to modify route tables. Is this right?
>
Assuming you are talking about B/D, yes you can do routing there if the
node accepts it..
> >You should repeat the same on wlan1 to mirror to wlan0 i.e on wlan1:
> >match ip src 192.168.2.0/24 ...
> >action mirred egress mirror dev wlan0
>
> Would this cause loops?
>
Ok, so this was the trick question;->
I dont see how the loop would happen - they are different "match" rules
i.e one is for 192.168.2.0/24 and the other is for 192.168.1.0/24
Whether it loops or not is easy for you to verify.
cheers,
jamal
^ permalink raw reply
* Re: net_sched 00/07: classful multiqueue dummy scheduler
From: Eric Dumazet @ 2009-09-07 13:00 UTC (permalink / raw)
To: David Miller; +Cc: kaber, netdev
In-Reply-To: <20090907.015039.154939751.davem@davemloft.net>
David Miller a écrit :
> I gave these patches a very basic bashing with NIU, and it
> seems to work from what I've tried.
>
> I know that Jarek has expressed some questions about the callback
> scheme used by the new mq classful qdisc, as well as some other
> issues, but we can refine this using followon patches.
>
> For now I'm pushing this out so that it gets wider testing.
>
> Thanks everyone!
Very interesting :)
Had very litle time to test this, but got problems very fast, if rate estimator configured.
(Here, eth2 maps to tg3, that uses a num_tx_queues of 5, even on non multiqueue device)
So its real_num_tx_queues is 1, but we can play with tc and mq
# tc qdisc replace dev eth2 handle 1: root estimator 1sec 8sec mq
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 62414 bytes 401 pkt (dropped 0, overlimits 0 requeues 0)
rate 5456bit 4pps backlog 0b 0p requeues 0
# tc qdisc replace dev eth2 parent 1:1 estimator 1sec 8sec pfifo
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 12984 bytes 88 pkt (dropped 0, overlimits 0 requeues 0)
rate 4368bit 4pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 12984 bytes 88 pkt (dropped 0, overlimits 0 requeues 0)
rate 9624bit 8pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 36781 bytes 244 pkt (dropped 0, overlimits 0 requeues 0)
rate 34360Mbit 205872pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 36781 bytes 244 pkt (dropped 0, overlimits 0 requeues 0)
rate 19824bit 16pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 52663 bytes 348 pkt (dropped 0, overlimits 0 requeues 0)
rate 17457Mbit 105605pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 52663 bytes 348 pkt (dropped 0, overlimits 0 requeues 0)
rate 22560bit 19pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 71775 bytes 473 pkt (dropped 0, overlimits 0 requeues 0)
rate 11838Mbit 47402pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 71775 bytes 473 pkt (dropped 0, overlimits 0 requeues 0)
rate 23880bit 20pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 94755 bytes 623 pkt (dropped 0, overlimits 0 requeues 0)
rate 3562Mbit 18621pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 94755 bytes 623 pkt (dropped 0, overlimits 0 requeues 0)
rate 24440bit 20pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 112501 bytes 741 pkt (dropped 0, overlimits 0 requeues 0)
rate 734270Kbit 9562pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 112501 bytes 741 pkt (dropped 0, overlimits 0 requeues 0)
rate 24632bit 20pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 127137 bytes 836 pkt (dropped 0, overlimits 0 requeues 0)
rate 25390Mbit 4913pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 127137 bytes 836 pkt (dropped 0, overlimits 0 requeues 0)
rate 24960bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 150745 bytes 992 pkt (dropped 0, overlimits 0 requeues 0)
rate 6212Mbit 1693pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 150745 bytes 992 pkt (dropped 0, overlimits 0 requeues 0)
rate 25032bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 174008 bytes 1144 pkt (dropped 0, overlimits 0 requeues 0)
rate 29377Mbit 674pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 174008 bytes 1144 pkt (dropped 0, overlimits 0 requeues 0)
rate 24904bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 185976 bytes 1224 pkt (dropped 0, overlimits 0 requeues 0)
rate 13093Mbit 408pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 185976 bytes 1224 pkt (dropped 0, overlimits 0 requeues 0)
rate 25288bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 232272 bytes 1530 pkt (dropped 0, overlimits 0 requeues 0)
rate 5196Mbit 57pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 232272 bytes 1530 pkt (dropped 0, overlimits 0 requeues 0)
rate 24784bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 300071 bytes 1977 pkt (dropped 0, overlimits 0 requeues 0)
rate 8988Mbit 6pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 300071 bytes 1977 pkt (dropped 0, overlimits 0 requeues 0)
rate 24432bit 20pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 377495 bytes 2490 pkt (dropped 0, overlimits 0 requeues 0)
rate 20429Mbit 2pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 377495 bytes 2490 pkt (dropped 0, overlimits 0 requeues 0)
rate 24520bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 448070 bytes 2958 pkt (dropped 0, overlimits 0 requeues 0)
rate 5726Mbit 4pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 448070 bytes 2958 pkt (dropped 0, overlimits 0 requeues 0)
rate 24576bit 20pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 519926 bytes 3435 pkt (dropped 0, overlimits 0 requeues 0)
rate 265505Kbit 3pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 519926 bytes 3435 pkt (dropped 0, overlimits 0 requeues 0)
rate 24920bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 522242 bytes 3449 pkt (dropped 0, overlimits 0 requeues 0)
rate 232389Kbit 62pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 522242 bytes 3449 pkt (dropped 0, overlimits 0 requeues 0)
rate 25304bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 528702 bytes 3491 pkt (dropped 0, overlimits 0 requeues 0)
rate 177925Kbit 49pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 528702 bytes 3491 pkt (dropped 0, overlimits 0 requeues 0)
rate 25400bit 21pps backlog 0b 0p requeues 0
<<<crash>>>
(On another term I had a "ping -i 0.1 192.168.20.120" that gave :
2009/08/07 14:53:42.498 64 bytes from 192.168.20.120: icmp_seq=1982 ttl=64 time=0.126 ms
2009/08/07 14:53:42.598 64 bytes from 192.168.20.120: icmp_seq=1983 ttl=64 time=0.118 ms
2009/08/07 14:53:42.698 64 bytes from 192.168.20.120: icmp_seq=1984 ttl=64 time=0.114 ms
2009/08/07 14:53:42.798 64 bytes from 192.168.20.120: icmp_seq=1985 ttl=64 time=0.123 ms
2009/08/07 14:53:42.898 64 bytes from 192.168.20.120: icmp_seq=1986 ttl=64 time=0.126 ms
2009/08/07 14:53:42.998 64 bytes from 192.168.20.120: icmp_seq=1987 ttl=64 time=0.119 ms
2009/08/07 14:53:43.098 64 bytes from 192.168.20.120: icmp_seq=1988 ttl=64 time=0.122 ms
2009/08/07 14:53:43.198 64 bytes from 192.168.20.120: icmp_seq=1989 ttl=64 time=0.119 ms
2009/08/07 14:53:43.298 64 bytes from 192.168.20.120: icmp_seq=1990 ttl=64 time=0.117 ms
2009/08/07 14:53:43.398 64 bytes from 192.168.20.120: icmp_seq=1991 ttl=64 time=0.117 ms
ping: sendmsg: No buffer space available
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: introduce primary_passive option
From: Jiri Pirko @ 2009-09-07 12:50 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: netdev, davem, fubar, bonding-devel
In-Reply-To: <4AA01F65.7010408@free.fr>
Thu, Sep 03, 2009 at 09:56:21PM CEST, nicolas.2p.debian@free.fr wrote:
> Jiri Pirko wrote:
>> (updated)
>>
>> In some cases there is not desirable to switch back to primary interface when
>> it's link recovers and rather stay with currently active one. We need to avoid
>> packetloss as much as we can in some cases. This is solved by introducing
>> primary_passive option. Note that enslaved primary slave is set as current
>> active no matter what.
>>
>> This patch depends on the following one:
>> [net-next-2.6] bonding: make ab_arp select active slaves as other modes
>> http://patchwork.ozlabs.org/patch/32684/
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>> diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
>> index d5181ce..e70fa8e 100644
>> --- a/Documentation/networking/bonding.txt
>> +++ b/Documentation/networking/bonding.txt
>> @@ -614,6 +614,17 @@ primary
>> The primary option is only valid for active-backup mode.
>> +primary_passive
>> +
>> + Specifies the behaviour of the primary slave in case of
>> + it's link recovery has been detected. By default (value 0) the
>> + primary slave is set as active slave immediately after the link
>> + recovery. If the value is 1 or 2 then current active slave doesn't
>> + change as long as it's link status doesn't change. This prevents
>> + the bonding device from flip-flopping. Plus if the value is 1 this
>> + behaviour happens only if the speed and duplex of primary slave is
>> + higher. It the value is 2 then it happens everytime.
>> +
>
> May I suggest the following option name and description instead ?
>
> -----
>
> primary_return
>
> Specifies the behavior of the current active slave when the primary was
> down and comes back up. This option is designed to prevent flip-flopping
> between the primary slave and other slaves. The possible values and
> their respective effects are:
>
> alway or 0 (default)
>
> The primary slave becomes the active slave whenever it comes
> back up.
>
> better or 1
>
> The primary slave becomes the active slave when it comes back
> up, if the speed and duplex of the primary slave is better
> than the speed and duplex of the current active slave.
>
> failure_only or 2
>
> The primary slave becomes the active slave only if the current
> active slave fails and the primary slave is up.
>
> When no slave are active, if the primary comes back up, it becomes the
> active slave, regardless of the value of primary_return.
>
> -----
>
> Then, to allow those logical names, I suggest you use the
> bond_parse_parm() function and the following constants and struct, to
> parse module params and sysfs configuration.
>
> enum {
> BOND_PRI_RETURN_ALWAYS = 0,
> BOND_PRI_RETURN_BETTER = 1,
> BOND_PRI_RETURN_FAILURE_ONLY = 2,
> };
>
> const struct bond_parm_tbl bond_pri_return_tbl[] = {
> { "always", BOND_PRI_RETURN_ALWAYS},
> { "better", BOND_PRI_RETURN_BETTER},
> { "failure_only", BOND_PRI_RETURN_FAILURE_ONLY},
> { NULL, -1},
> };
>
> Nicolas.
Ok, I like this, but I would stay rather with Jay's suggestion to call this
option primary_passive. Seems more accurate to me.
I'm going to repost soon.
Jirka
>
>> updelay
>> Specifies the time, in milliseconds, to wait before enabling a
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 699bfdd..65066c1 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -94,6 +94,7 @@ static int downdelay;
>> static int use_carrier = 1;
>> static char *mode;
>> static char *primary;
>> +static int primary_passive;
>> static char *lacp_rate;
>> static char *ad_select;
>> static char *xmit_hash_policy;
>> @@ -126,6 +127,9 @@ MODULE_PARM_DESC(mode, "Mode of operation : 0 for balance-rr, "
>> "6 for balance-alb");
>> module_param(primary, charp, 0);
>> MODULE_PARM_DESC(primary, "Primary network device to use");
>> +module_param(primary_passive, int, 0);
>> +MODULE_PARM_DESC(primary_passive, "Do not set primary slave active once it comes up; "
>> + "0 for off (default), 1 for on only if speed of primary is not higher, 2 for on");
>> module_param(lacp_rate, charp, 0);
>> MODULE_PARM_DESC(lacp_rate, "LACPDU tx rate to request from 802.3ad partner "
>> "(slow/fast)");
>> @@ -1070,6 +1074,25 @@ out:
>> }
>> +static bool bond_should_loose_active(struct bonding *bond)
>> +{
>> + struct slave *prim = bond->primary_slave;
>> + struct slave *curr = bond->curr_active_slave;
>> +
>> + if (!prim || !curr || curr->link != BOND_LINK_UP)
>> + return true;
>> + if (bond->force_primary) {
>> + bond->force_primary = false;
>> + return true;
>> + }
>> + if (bond->params.primary_passive == 1 &&
>> + (prim->speed < curr->speed ||
>> + (prim->speed == curr->speed && prim->duplex <= curr->duplex)))
>> + return false;
>> + if (bond->params.primary_passive == 2)
>> + return false;
>> + return true;
>> +}
>> /**
>> * find_best_interface - select the best available slave to be the active one
>> @@ -1094,7 +1117,8 @@ static struct slave *bond_find_best_slave(struct bonding *bond)
>> }
>> if ((bond->primary_slave) &&
>> - bond->primary_slave->link == BOND_LINK_UP) {
>> + bond->primary_slave->link == BOND_LINK_UP &&
>> + bond_should_loose_active(bond)) {
>> new_active = bond->primary_slave;
>> }
>> @@ -1675,8 +1699,10 @@ int bond_enslave(struct net_device *bond_dev,
>> struct net_device *slave_dev)
>> if (USES_PRIMARY(bond->params.mode) && bond->params.primary[0]) {
>> /* if there is a primary slave, remember it */
>> - if (strcmp(bond->params.primary, new_slave->dev->name) == 0)
>> + if (strcmp(bond->params.primary, new_slave->dev->name) == 0) {
>> bond->primary_slave = new_slave;
>> + bond->force_primary = true;
>> + }
>> }
>> write_lock_bh(&bond->curr_slave_lock);
>> @@ -4942,6 +4968,18 @@ static int bond_check_params(struct bond_params *params)
>> primary = NULL;
>> }
>> + if (primary) {
>> + if ((primary_passive != 0) && (primary_passive != 1) &&
>> + (primary_passive != 2)) {
>> + pr_warning(DRV_NAME
>> + ": Warning: primary_passive module parameter "
>> + "(%d), not of valid value (0/1/2), so it was "
>> + "set to 0\n",
>> + primary_passive);
>> + primary_passive = 0;
>> + }
>> + }
>> +
>> if (fail_over_mac) {
>> fail_over_mac_value = bond_parse_parm(fail_over_mac,
>> fail_over_mac_tbl);
>> @@ -4973,6 +5011,7 @@ static int bond_check_params(struct bond_params *params)
>> params->use_carrier = use_carrier;
>> params->lacp_fast = lacp_fast;
>> params->primary[0] = 0;
>> + params->primary_passive = primary_passive;
>> params->fail_over_mac = fail_over_mac_value;
>> if (primary) {
>> diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
>> index 6044e12..e813d48 100644
>> --- a/drivers/net/bonding/bond_sysfs.c
>> +++ b/drivers/net/bonding/bond_sysfs.c
>> @@ -1212,6 +1212,59 @@ static DEVICE_ATTR(primary, S_IRUGO | S_IWUSR,
>> bonding_show_primary, bonding_store_primary);
>> /*
>> + * Show and set the primary_passive flag.
>> + */
>> +static ssize_t bonding_show_primary_passive(struct device *d,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct bonding *bond = to_bond(d);
>> +
>> + return sprintf(buf, "%d\n", bond->params.primary_passive);
>> +}
>> +
>> +static ssize_t bonding_store_primary_passive(struct device *d,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + int new_value, ret = count;
>> + struct bonding *bond = to_bond(d);
>> +
>> + if (!rtnl_trylock())
>> + return restart_syscall();
>> +
>> + if (sscanf(buf, "%d", &new_value) != 1) {
>> + pr_err(DRV_NAME
>> + ": %s: no primary_passive value specified.\n",
>> + bond->dev->name);
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> + if (new_value == 0 || new_value == 1 || new_value == 2) {
>> + bond->params.primary_passive = new_value;
>> + pr_info(DRV_NAME ": %s: Setting primary_passive to %d.\n",
>> + bond->dev->name, new_value);
>> + if (new_value == 0 || new_value == 1) {
>> + bond->force_primary = true;
>> + read_lock(&bond->lock);
>> + write_lock_bh(&bond->curr_slave_lock);
>> + bond_select_active_slave(bond);
>> + write_unlock_bh(&bond->curr_slave_lock);
>> + read_unlock(&bond->lock);
>> + }
>> + } else {
>> + pr_info(DRV_NAME
>> + ": %s: Ignoring invalid primary_passive value %d.\n",
>> + bond->dev->name, new_value);
>> + }
>> +out:
>> + rtnl_unlock();
>> + return count;
>> +}
>> +static DEVICE_ATTR(primary_passive, S_IRUGO | S_IWUSR,
>> + bonding_show_primary_passive, bonding_store_primary_passive);
>> +
>> +/*
>> * Show and set the use_carrier flag.
>> */
>> static ssize_t bonding_show_carrier(struct device *d,
>> @@ -1500,6 +1553,7 @@ static struct attribute *per_bond_attrs[] = {
>> &dev_attr_num_unsol_na.attr,
>> &dev_attr_miimon.attr,
>> &dev_attr_primary.attr,
>> + &dev_attr_primary_passive.attr,
>> &dev_attr_use_carrier.attr,
>> &dev_attr_active_slave.attr,
>> &dev_attr_mii_status.attr,
>> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
>> index 6290a50..b6287e0 100644
>> --- a/drivers/net/bonding/bonding.h
>> +++ b/drivers/net/bonding/bonding.h
>> @@ -131,6 +131,7 @@ struct bond_params {
>> int lacp_fast;
>> int ad_select;
>> char primary[IFNAMSIZ];
>> + int primary_passive;
>> __be32 arp_targets[BOND_MAX_ARP_TARGETS];
>> };
>> @@ -190,6 +191,7 @@ struct bonding {
>> struct slave *curr_active_slave;
>> struct slave *current_arp_slave;
>> struct slave *primary_slave;
>> + bool force_primary;
>> s32 slave_cnt; /* never change this value outside the attach/detach wrappers */
>> rwlock_t lock;
>> rwlock_t curr_slave_lock;
>>
>
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: Xiaofei Wu @ 2009-09-07 12:38 UTC (permalink / raw)
To: hadi; +Cc: linux netdev
In-Reply-To: <1252260806.4580.6.camel@dogo.mojatatu.com>
>> On node A,
>> wlan0, IP address 192.168.1.1/24 ; wlan1, IP address 192.168.2.1/24
>> I use command 'tc filter add dev wlan0 ... match ip src 192.168.1.0/24 ...
>> action mirred egress mirror dev wlan1' to mirror packets.
>> When I use 'tcpdump -i wlan1', I can 'see' the packets 'A(wlan0)->B' (node B will forward them to C).
>> How to forward the mirroring packets 'A(wlan1)' to D (then, node D forwards them to C) ?
>>
>>
>Is there a trick to this question or is it too basic? ;->
I am sorry.
Maybe it is very easy for you. But I didn't find enough documents(or examples) about 'tc' to help me.
I just want to know:
1) Could I forward the mirroring packets to another node ,and then route it to the destination(if I use
iproute2 (ip, tc ...) )? I described my purpose in my last email.
2) After I mirrored the packets, I should use 'ip route' , 'ip rule' to modify route tables. Is this right?
>You should repeat the same on wlan1 to mirror to wlan0 i.e on wlan1:
>match ip src 192.168.2.0/24 ...
>action mirred egress mirror dev wlan0
Would this cause loops?
>Note the node C will receive "wrong" src mac addresses on those
>interfaces; you may want to correct/edit them first before you send them
>out. Look at using the pedit action.
Regards,
Wu
^ permalink raw reply
* [PATCH] headers: net/ipv[46]/protocol.c header trim
From: Alexey Dobriyan @ 2009-09-07 12:38 UTC (permalink / raw)
To: davem; +Cc: netdev
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
net/ipv4/protocol.c | 19 ++-----------------
net/ipv6/protocol.c | 15 ++-------------
2 files changed, 4 insertions(+), 30 deletions(-)
--- a/net/ipv4/protocol.c
+++ b/net/ipv4/protocol.c
@@ -22,26 +22,11 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
-
-#include <asm/uaccess.h>
-#include <asm/system.h>
+#include <linux/cache.h>
#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/string.h>
-#include <linux/socket.h>
-#include <linux/in.h>
-#include <linux/inet.h>
#include <linux/netdevice.h>
-#include <linux/timer.h>
-#include <net/ip.h>
+#include <linux/spinlock.h>
#include <net/protocol.h>
-#include <linux/skbuff.h>
-#include <net/sock.h>
-#include <net/icmp.h>
-#include <net/udp.h>
-#include <net/ipip.h>
-#include <linux/igmp.h>
struct net_protocol *inet_protos[MAX_INET_PROTOS] ____cacheline_aligned_in_smp;
static DEFINE_SPINLOCK(inet_proto_lock);
--- a/net/ipv6/protocol.c
+++ b/net/ipv6/protocol.c
@@ -20,20 +20,9 @@
* - Removed unused variable 'inet6_protocol_base'
* - Modified inet6_del_protocol() to correctly maintain copy bit.
*/
-
-#include <linux/errno.h>
-#include <linux/types.h>
-#include <linux/socket.h>
-#include <linux/sockios.h>
-#include <linux/net.h>
-#include <linux/in6.h>
+#include <linux/module.h>
#include <linux/netdevice.h>
-#include <linux/if_arp.h>
-
-#include <net/sock.h>
-#include <net/snmp.h>
-
-#include <net/ipv6.h>
+#include <linux/spinlock.h>
#include <net/protocol.h>
struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
^ permalink raw reply
* Re: [PATCH 1/2] Add an alternative cs89x0 driver
From: Kurt Van Dijck @ 2009-09-07 12:35 UTC (permalink / raw)
To: Sascha Hauer; +Cc: netdev
In-Reply-To: <20090907102434.GC31592@pengutronix.de>
On Mon, Sep 07, 2009 at 12:24:34PM +0200, Sascha Hauer wrote:
> Date: Mon, 7 Sep 2009 12:24:34 +0200
> Subject: Re: [PATCH 1/2] Add an alternative cs89x0 driver
> From: Sascha Hauer <s.hauer@pengutronix.de>
> To: Kurt Van Dijck <kurt.van.dijck@eia.be>
> Cc: netdev@vger.kernel.org
> List-ID: <netdev.vger.kernel.org>
>
> Hi Kurt,
>
> On Wed, Aug 26, 2009 at 12:46:34PM +0200, Kurt Van Dijck wrote:
> > Hi Sacha,
> >
> > I'm using a 2.6.25.
> > Converting to your platform_device based driver,
> > I needed to configure the irq (see patch, irq flags).
> > Looking in the old cs89x0.c, it's done in the driver. Should I have
> > configured the irq level elsewhere? Or is this patch valid to do?
>
> This is the way to go. I don't know if the cs89x0 has configurable
> interrupt levels though.
I haven't read any spec about cs89x0, but by looking in the existing
code:
1) IRQF_TRIGGER_HIGH seems like the default
2) the old driver didn't do any irq config in the chip either.
May I assume you were lucky testing the driver on a platform that had
IRQF_TRIGGER_HIGH per default?
I have it running (with patch) on a iMX31 (arm)
Kurt
>
> Sascha
>
> >
> > Kurt
> >
> > Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
> > ---
> > Index: drivers/net/cirrus-cs89x0.c
> > ===================================================================
> > --- drivers/net/cirrus-cs89x0.c (revision 7107)
> > +++ drivers/net/cirrus-cs89x0.c (working copy)
> > @@ -487,7 +487,8 @@
> > }
> >
> > /* install interrupt handler */
> > - result = request_irq(ndev->irq, &cirrus_interrupt, 0, ndev->name, ndev);
> > + result = request_irq(ndev->irq, &cirrus_interrupt,
> > + IRQF_TRIGGER_HIGH, ndev->name, ndev);
> > if (result < 0) {
> > printk(KERN_ERR "%s: could not register interrupt %d\n",
> > ndev->name, ndev->irq);
> >
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Sebastian Haas @ 2009-09-07 11:06 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Wolfgang Grandegger, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4DC09.8070803@hartkopp.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Okay, thanks for the tips. Lets see what I can create today.
Sebastian
Oliver Hartkopp schrieb:
> Wolfgang Grandegger wrote:
>> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Wolfgang,
>>>
>>> Wolfgang Grandegger schrieb:
>>>> Hi Sebastian,
>>>>
>>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Oliver,
>>>>>
>>>>> I'm not yet sure how to actually start the development. There is so
>>>>> much
>>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>>> devices and make tests here.
>>>>>
>>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>>> CAN
>>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>>> part and write the USB part.
>>>>>
>>>>> I'll also write a specification which contains any information you need
>>>>> to develop a CAN driver for the device (commands, sequences, error
>>>>> handling).
>>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>>> limited resource. Progress depends on funding to a certain extend.
>>> Money is also a limited resource. ;-)
>>>
>>> Let's become serious again, I know and respect that many of Socket-CAN
>>> and the Staging developers spend their free time working on it. We will
>>> of course work on the driver, but since we've not much time it may take
>>> several months. If someone wants to help, we would be very glad and
>>> happy to support the person as far as we can with devices, answers and
>>> tests.
>> OK, no problem. I really appreciate your support for Socket-CAN so far.
>
> Indeed. Me too.
>
> I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
> all the procfs and the chardev stuff and then create a CAN netdev when you
> identified an USB node analogue to
>
> /* Detect available channels */
> for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
> dev = alloc_sja1000dev(0);
> if (dev == NULL) {
> err = -ENOMEM;
> goto failure_cleanup;
> }
>
> card->net_dev[i] = dev;
> priv = netdev_priv(dev);
> priv->priv = card;
> SET_NETDEV_DEV(dev, &pdev->dev);
>
> as you know from your ems_pcmcia.c driver
>
> and
>
> struct net_device *alloc_sja1000dev(int sizeof_priv)
> {
> struct net_device *dev;
> struct sja1000_priv *priv;
>
> dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
> if (!dev)
> return NULL;
>
> priv = netdev_priv(dev);
>
> priv->dev = dev;
> priv->can.bittiming_const = &sja1000_bittiming_const;
> priv->can.do_set_bittiming = sja1000_set_bittiming;
> priv->can.do_set_mode = sja1000_set_mode;
>
> if (sizeof_priv)
> priv->priv = (void *)priv + sizeof(struct sja1000_priv);
>
> return dev;
> }
>
> as you know from the sja1000.c (which can probably be used for the
> LPC2119_PRODUCT_ID we should try to implement first).
>
> Then we need something like this stuff
>
> static const struct net_device_ops sja1000_netdev_ops = {
> .ndo_open = sja1000_open,
> .ndo_stop = sja1000_close,
> .ndo_start_xmit = sja1000_start_xmit,
> };
>
> int register_sja1000dev(struct net_device *dev)
> {
> if (!sja1000_probe_chip(dev))
> return -ENODEV;
>
> dev->netdev_ops = &sja1000_netdev_ops;
>
> dev->flags |= IFF_ECHO; /* we support local echo */
>
> set_reset_mode(dev);
> chipset_init(dev);
>
> return register_candev(dev);
> }
>
> from sja1000.c
>
> And then we have an USB CAN node that has a belonging CAN netdevice (maybe
> there is something else we can look at that's used in other USB ethernet
> adapters).
>
> I know from the PEAK USB driver at
>
> http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
>
> that i just needed to duplicate and modify the usb rx/tx stuff and redirect
> the CAN frames into the network stack. But this PEAK driver does not have a
> netlink configuration interface and can only be taken as a limited example ...
>
> I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
> ?) is prepared as described above, one can go and connect the rx/tx dataflow
> and the netlink configuration.
>
> Unfortunately i'm short of time the next two weeks but maybe you can start and
> create such a new C-file (probably based on ems_pcmcia.c) ?
>
> Best regards,
> Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqk6TcACgkQpqRB8PJG7XzpQACePuMXFX6pSg7EyssTNnDfVomv
Lm0AnA7WKWLHfRny2iF5krEaT966WmPJ
=07pa
-----END PGP SIGNATURE-----
--
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106
Phone: +49-8441-490260
Fax : +49-8441-81860
http://www.ems-wuensche.com
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Wolfgang Grandegger @ 2009-09-07 10:27 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Sebastian Haas, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4DC09.8070803@hartkopp.net>
On 09/07/2009 12:10 PM, Oliver Hartkopp wrote:
> Wolfgang Grandegger wrote:
>> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Wolfgang,
>>>
>>> Wolfgang Grandegger schrieb:
>>>> Hi Sebastian,
>>>>
>>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Oliver,
>>>>>
>>>>> I'm not yet sure how to actually start the development. There is so
>>>>> much
>>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>>> devices and make tests here.
>>>>>
>>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>>> CAN
>>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>>> part and write the USB part.
>>>>>
>>>>> I'll also write a specification which contains any information you need
>>>>> to develop a CAN driver for the device (commands, sequences, error
>>>>> handling).
>>>>
>>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>>> limited resource. Progress depends on funding to a certain extend.
>>> Money is also a limited resource. ;-)
>>>
>>> Let's become serious again, I know and respect that many of Socket-CAN
>>> and the Staging developers spend their free time working on it. We will
>>> of course work on the driver, but since we've not much time it may take
>>> several months. If someone wants to help, we would be very glad and
>>> happy to support the person as far as we can with devices, answers and
>>> tests.
>>
>> OK, no problem. I really appreciate your support for Socket-CAN so far.
>
> Indeed. Me too.
>
> I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
> all the procfs and the chardev stuff and then create a CAN netdev when you
> identified an USB node analogue to
>
> /* Detect available channels */
> for (i = 0; i< EMS_PCMCIA_MAX_CHAN; i++) {
> dev = alloc_sja1000dev(0);
> if (dev == NULL) {
> err = -ENOMEM;
> goto failure_cleanup;
> }
>
> card->net_dev[i] = dev;
> priv = netdev_priv(dev);
> priv->priv = card;
> SET_NETDEV_DEV(dev,&pdev->dev);
>
> as you know from your ems_pcmcia.c driver
>
> and
>
> struct net_device *alloc_sja1000dev(int sizeof_priv)
> {
> struct net_device *dev;
> struct sja1000_priv *priv;
>
> dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
> if (!dev)
> return NULL;
>
> priv = netdev_priv(dev);
>
> priv->dev = dev;
> priv->can.bittiming_const =&sja1000_bittiming_const;
> priv->can.do_set_bittiming = sja1000_set_bittiming;
> priv->can.do_set_mode = sja1000_set_mode;
>
> if (sizeof_priv)
> priv->priv = (void *)priv + sizeof(struct sja1000_priv);
>
> return dev;
> }
>
> as you know from the sja1000.c (which can probably be used for the
> LPC2119_PRODUCT_ID we should try to implement first).
>
> Then we need something like this stuff
>
> static const struct net_device_ops sja1000_netdev_ops = {
> .ndo_open = sja1000_open,
> .ndo_stop = sja1000_close,
> .ndo_start_xmit = sja1000_start_xmit,
> };
>
> int register_sja1000dev(struct net_device *dev)
> {
> if (!sja1000_probe_chip(dev))
> return -ENODEV;
>
> dev->netdev_ops =&sja1000_netdev_ops;
>
> dev->flags |= IFF_ECHO; /* we support local echo */
>
> set_reset_mode(dev);
> chipset_init(dev);
>
> return register_candev(dev);
> }
>
> from sja1000.c
>
> And then we have an USB CAN node that has a belonging CAN netdevice (maybe
> there is something else we can look at that's used in other USB ethernet
> adapters).
>
> I know from the PEAK USB driver at
>
> http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
>
> that i just needed to duplicate and modify the usb rx/tx stuff and redirect
> the CAN frames into the network stack. But this PEAK driver does not have a
> netlink configuration interface and can only be taken as a limited example ...
>
> I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
> ?) is prepared as described above, one can go and connect the rx/tx dataflow
> and the netlink configuration.
>
> Unfortunately i'm short of time the next two weeks but maybe you can start and
> create such a new C-file (probably based on ems_pcmcia.c) ?
Also, there are USB network driver in "drivers/net/usb/" which might
serve as examples.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 1/2] Add an alternative cs89x0 driver
From: Sascha Hauer @ 2009-09-07 10:24 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: netdev
In-Reply-To: <20090826104634.GA14425@e-circ.dyndns.org>
Hi Kurt,
On Wed, Aug 26, 2009 at 12:46:34PM +0200, Kurt Van Dijck wrote:
> Hi Sacha,
>
> I'm using a 2.6.25.
> Converting to your platform_device based driver,
> I needed to configure the irq (see patch, irq flags).
> Looking in the old cs89x0.c, it's done in the driver. Should I have
> configured the irq level elsewhere? Or is this patch valid to do?
This is the way to go. I don't know if the cs89x0 has configurable
interrupt levels though.
Sascha
>
> Kurt
>
> Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
> ---
> Index: drivers/net/cirrus-cs89x0.c
> ===================================================================
> --- drivers/net/cirrus-cs89x0.c (revision 7107)
> +++ drivers/net/cirrus-cs89x0.c (working copy)
> @@ -487,7 +487,8 @@
> }
>
> /* install interrupt handler */
> - result = request_irq(ndev->irq, &cirrus_interrupt, 0, ndev->name, ndev);
> + result = request_irq(ndev->irq, &cirrus_interrupt,
> + IRQF_TRIGGER_HIGH, ndev->name, ndev);
> if (result < 0) {
> printk(KERN_ERR "%s: could not register interrupt %d\n",
> ndev->name, ndev->irq);
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-09-07 10:15 UTC (permalink / raw)
To: Ira W. Snyder
Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, Rusty Russell, s.hetze
In-Reply-To: <20090903183945.GF28651@ovro.caltech.edu>
On Thu, Sep 03, 2009 at 11:39:45AM -0700, Ira W. Snyder wrote:
> On Thu, Aug 27, 2009 at 07:07:50PM +0300, Michael S. Tsirkin wrote:
> > What it is: vhost net is a character device that can be used to reduce
> > the number of system calls involved in virtio networking.
> > Existing virtio net code is used in the guest without modification.
> >
> > There's similarity with vringfd, with some differences and reduced scope
> > - uses eventfd for signalling
> > - structures can be moved around in memory at any time (good for migration)
> > - support memory table and not just an offset (needed for kvm)
> >
> > common virtio related code has been put in a separate file vhost.c and
> > can be made into a separate module if/when more backends appear. I used
> > Rusty's lguest.c as the source for developing this part : this supplied
> > me with witty comments I wouldn't be able to write myself.
> >
> > What it is not: vhost net is not a bus, and not a generic new system
> > call. No assumptions are made on how guest performs hypercalls.
> > Userspace hypervisors are supported as well as kvm.
> >
> > How it works: Basically, we connect virtio frontend (configured by
> > userspace) to a backend. The backend could be a network device, or a
> > tun-like device. In this version I only support raw socket as a backend,
> > which can be bound to e.g. SR IOV, or to macvlan device. Backend is
> > also configured by userspace, including vlan/mac etc.
> >
> > Status:
> > This works for me, and I haven't see any crashes.
> > I have done some light benchmarking (with v4), compared to userspace, I
> > see improved latency (as I save up to 4 system calls per packet) but not
> > bandwidth/CPU (as TSO and interrupt mitigation are not supported). For
> > ping benchmark (where there's no TSO) troughput is also improved.
> >
> > Features that I plan to look at in the future:
> > - tap support
> > - TSO
> > - interrupt mitigation
> > - zero copy
> >
>
> Hello Michael,
>
> I've started looking at vhost with the intention of using it over PCI to
> connect physical machines together.
>
> The part that I am struggling with the most is figuring out which parts
> of the rings are in the host's memory, and which parts are in the
> guest's memory.
All rings are in guest's memory, to match existing virtio code. vhost
assumes that the memory space of the hypervisor userspace process covers
the whole of guest memory. And there's a translation table.
Ring addresses are userspace addresses, they do not undergo translation.
> If I understand everything correctly, the rings are all userspace
> addresses, which means that they can be moved around in physical memory,
> and get pushed out to swap.
Unless they are locked, yes.
> AFAIK, this is impossible to handle when
> connecting two physical systems, you'd need the rings available in IO
> memory (PCI memory), so you can ioreadXX() them instead. To the best of
> my knowledge, I shouldn't be using copy_to_user() on an __iomem address.
> Also, having them migrate around in memory would be a bad thing.
>
> Also, I'm having trouble figuring out how the packet contents are
> actually copied from one system to the other. Could you point this out
> for me?
The code in net/packet/af_packet.c does it when vhost calls sendmsg.
> Is there somewhere I can find the userspace code (kvm, qemu, lguest,
> etc.) code needed for interacting with the vhost misc device so I can
> get a better idea of how userspace is supposed to work?
Look in archives for kvm@vger.kernel.org. the subject is qemu-kvm: vhost net.
> (Features
> negotiation, etc.)
>
> Thanks,
> Ira
That's not yet implemented as there are no features yet. I'm working on
tap support, which will add a feature bit. Overall, qemu does an ioctl
to query supported features, and then acks them with another ioctl. I'm
also trying to avoid duplicating functionality available elsewhere. So
that to check e.g. TSO support, you'd just look at the underlying
hardware device you are binding to.
--
MST
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Oliver Hartkopp @ 2009-09-07 10:10 UTC (permalink / raw)
To: Sebastian Haas
Cc: Wolfgang Grandegger, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4CB3F.3060200@grandegger.com>
Wolfgang Grandegger wrote:
> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Wolfgang,
>>
>> Wolfgang Grandegger schrieb:
>>> Hi Sebastian,
>>>
>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Oliver,
>>>>
>>>> I'm not yet sure how to actually start the development. There is so
>>>> much
>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>> devices and make tests here.
>>>>
>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>> CAN
>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>> part and write the USB part.
>>>>
>>>> I'll also write a specification which contains any information you need
>>>> to develop a CAN driver for the device (commands, sequences, error
>>>> handling).
>>>
>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>> limited resource. Progress depends on funding to a certain extend.
>> Money is also a limited resource. ;-)
>>
>> Let's become serious again, I know and respect that many of Socket-CAN
>> and the Staging developers spend their free time working on it. We will
>> of course work on the driver, but since we've not much time it may take
>> several months. If someone wants to help, we would be very glad and
>> happy to support the person as far as we can with devices, answers and
>> tests.
>
> OK, no problem. I really appreciate your support for Socket-CAN so far.
Indeed. Me too.
I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
all the procfs and the chardev stuff and then create a CAN netdev when you
identified an USB node analogue to
/* Detect available channels */
for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
dev = alloc_sja1000dev(0);
if (dev == NULL) {
err = -ENOMEM;
goto failure_cleanup;
}
card->net_dev[i] = dev;
priv = netdev_priv(dev);
priv->priv = card;
SET_NETDEV_DEV(dev, &pdev->dev);
as you know from your ems_pcmcia.c driver
and
struct net_device *alloc_sja1000dev(int sizeof_priv)
{
struct net_device *dev;
struct sja1000_priv *priv;
dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
if (!dev)
return NULL;
priv = netdev_priv(dev);
priv->dev = dev;
priv->can.bittiming_const = &sja1000_bittiming_const;
priv->can.do_set_bittiming = sja1000_set_bittiming;
priv->can.do_set_mode = sja1000_set_mode;
if (sizeof_priv)
priv->priv = (void *)priv + sizeof(struct sja1000_priv);
return dev;
}
as you know from the sja1000.c (which can probably be used for the
LPC2119_PRODUCT_ID we should try to implement first).
Then we need something like this stuff
static const struct net_device_ops sja1000_netdev_ops = {
.ndo_open = sja1000_open,
.ndo_stop = sja1000_close,
.ndo_start_xmit = sja1000_start_xmit,
};
int register_sja1000dev(struct net_device *dev)
{
if (!sja1000_probe_chip(dev))
return -ENODEV;
dev->netdev_ops = &sja1000_netdev_ops;
dev->flags |= IFF_ECHO; /* we support local echo */
set_reset_mode(dev);
chipset_init(dev);
return register_candev(dev);
}
from sja1000.c
And then we have an USB CAN node that has a belonging CAN netdevice (maybe
there is something else we can look at that's used in other USB ethernet
adapters).
I know from the PEAK USB driver at
http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
that i just needed to duplicate and modify the usb rx/tx stuff and redirect
the CAN frames into the network stack. But this PEAK driver does not have a
netlink configuration interface and can only be taken as a limited example ...
I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
?) is prepared as described above, one can go and connect the rx/tx dataflow
and the netlink configuration.
Unfortunately i'm short of time the next two weeks but maybe you can start and
create such a new C-file (probably based on ems_pcmcia.c) ?
Best regards,
Oliver
^ permalink raw reply
* [PATCH 2.6.31-rc9] mv643xx_eth.c: remove unused txq_set_wrr()
From: Mikael Pettersson @ 2009-09-07 9:59 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: linux-kernel, netdev
The txq_set_wrr() function in drivers/net/mv643xx_eth.c is
unused, not even referenced under #if 0 or something like that,
which results in a compile-time warning:
drivers/net/mv643xx_eth.c:1070: warning: 'txq_set_wrr' defined but not used
Fix: remove it.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
---
drivers/net/mv643xx_eth.c | 34 ----------------------------------
1 file changed, 34 deletions(-)
--- linux-2.6.31-rc9/drivers/net/mv643xx_eth.c.~1~ 2009-09-06 12:20:57.000000000 +0200
+++ linux-2.6.31-rc9/drivers/net/mv643xx_eth.c 2009-09-07 11:36:32.000000000 +0200
@@ -1066,40 +1066,6 @@ static void txq_set_fixed_prio_mode(stru
}
}
-static void txq_set_wrr(struct tx_queue *txq, int weight)
-{
- struct mv643xx_eth_private *mp = txq_to_mp(txq);
- int off;
- u32 val;
-
- /*
- * Turn off fixed priority mode.
- */
- off = 0;
- switch (mp->shared->tx_bw_control) {
- case TX_BW_CONTROL_OLD_LAYOUT:
- off = TXQ_FIX_PRIO_CONF;
- break;
- case TX_BW_CONTROL_NEW_LAYOUT:
- off = TXQ_FIX_PRIO_CONF_MOVED;
- break;
- }
-
- if (off) {
- val = rdlp(mp, off);
- val &= ~(1 << txq->index);
- wrlp(mp, off, val);
-
- /*
- * Configure WRR weight for this queue.
- */
-
- val = rdlp(mp, off);
- val = (val & ~0xff) | (weight & 0xff);
- wrlp(mp, TXQ_BW_WRR_CONF(txq->index), val);
- }
-}
-
/* mii management interface *************************************************/
static irqreturn_t mv643xx_eth_err_irq(int irq, void *dev_id)
^ permalink raw reply
* Re: net_sched 00/07: classful multiqueue dummy scheduler
From: Jarek Poplawski @ 2009-09-07 9:46 UTC (permalink / raw)
To: David Miller; +Cc: kaber, netdev
In-Reply-To: <20090907.015039.154939751.davem@davemloft.net>
On 07-09-2009 10:50, David Miller wrote:
> I gave these patches a very basic bashing with NIU, and it
> seems to work from what I've tried.
>
> I know that Jarek has expressed some questions about the callback
> scheme used by the new mq classful qdisc, as well as some other
> issues, but we can refine this using followon patches.
>
> For now I'm pushing this out so that it gets wider testing.
Sure, it should make the further discussion easier (at least until
a new backward compatibilty starts to matter ;-).
Thanks,
Jarek P.
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: David Miller @ 2009-09-07 9:18 UTC (permalink / raw)
To: tilman; +Cc: linux-kernel, netdev, i4ldeveloper, hjlipp, isdn
In-Reply-To: <4AA4CE49.7040501@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Mon, 07 Sep 2009 11:11:37 +0200
> David Miller schrieb:
>> From: Tilman Schmidt <tilman@imap.cc>
>> Date: Sun, 6 Sep 2009 20:58:52 +0200 (CEST)
>>
>>> Would you please take these into your net tree for 2.6.32.
>>
>> So do we have an ISDN maintainer or not?
>>
>> If Karsten is still maintaining things, your work should
>> go through him not me.
>
> Last atime I asked, you said me you would take ISDN patches.
> Could you two please sort this out?
Sure.
Karsten, are you going to handle ISDN and ISDN driver patches
and queue them up to me?
> I am just a humble driver maintainer knowing nothing about
> maintainer politics.
Understood.
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Tilman Schmidt @ 2009-09-07 9:11 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, i4ldeveloper, hjlipp
In-Reply-To: <20090907.020038.248900438.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
David Miller schrieb:
> From: Tilman Schmidt <tilman@imap.cc>
> Date: Sun, 6 Sep 2009 20:58:52 +0200 (CEST)
>
>> Would you please take these into your net tree for 2.6.32.
>
> So do we have an ISDN maintainer or not?
>
> If Karsten is still maintaining things, your work should
> go through him not me.
Last atime I asked, you said me you would take ISDN patches.
Could you two please sort this out? I am just a humble driver
maintainer knowing nothing about maintainer politics.
> This also applies to the 4 part CAPI patch set you sent as
> well.
>
> I'm tossing these from patchwork as they're not my realm.
> :-)
I guess I have no recourse against that.
:-(
T.
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Tilman Schmidt @ 2009-09-07 9:07 UTC (permalink / raw)
To: Daniel Walker; +Cc: davem, linux-kernel, netdev, i4ldeveloper, Hansjoerg Lipp
In-Reply-To: <1252286806.2139.1.camel@desktop>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
Daniel,
thanks for taking a look at my patches.
On Sun, 06 Sep 2009 18:26:46 -0700, Daniel Walker wrote:
> patches 6,7,10, and 12 all have checkpatch errors. Could you fix those?
I have reissued patch 7, exchanging the "static" and "inline" keywords
as requested.
The other patches I'd much prefer to keep as they are. The "ERRORs"
checkpatch.pl reported for them are results of keeping to the existing
formatting of the patched files. Completely reformatting them would
cloud the actual changes made by the patches.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: David Miller @ 2009-09-07 9:00 UTC (permalink / raw)
To: tilman; +Cc: linux-kernel, netdev, i4ldeveloper, hjlipp
In-Reply-To: <20090906-patch-gigaset-00.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Sun, 6 Sep 2009 20:58:52 +0200 (CEST)
> Would you please take these into your net tree for 2.6.32.
So do we have an ISDN maintainer or not?
If Karsten is still maintaining things, your work should
go through him not me.
This also applies to the 4 part CAPI patch set you sent as
well.
I'm tossing these from patchwork as they're not my realm.
:-)
^ 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