* [PATCH 09/10] nl802154: support START-CONFIRM primitive
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-9-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/net/nl802154.h | 9 +++++++++
net/ieee802154/netlink.c | 32 ++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index 6096096..e554ecd 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -114,4 +114,13 @@ int ieee802154_nl_scan_confirm(struct net_device *dev,
int ieee802154_nl_beacon_indic(struct net_device *dev, u16 panid,
u16 coord_addr);
+/**
+ * ieee802154_nl_start_confirm - Notify userland of completion of start.
+ * @dev: The device which was instructed to scan.
+ * @status: The status of the scan operation.
+ *
+ * Note: This is in section 7.1.14 of the IEEE 802.15.4 document.
+ */
+int ieee802154_nl_start_confirm(struct net_device *dev, u8 status);
+
#endif
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index 6fc6d6f..70a067e 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -31,6 +31,7 @@
#include <linux/nl802154.h>
#include <net/af_ieee802154.h>
#include <net/nl802154.h>
+#include <net/ieee802154.h>
#include <net/ieee802154_netdev.h>
static unsigned int ieee802154_seq_num;
@@ -262,6 +263,31 @@ nla_put_failure:
}
EXPORT_SYMBOL(ieee802154_nl_scan_confirm);
+int ieee802154_nl_start_confirm(struct net_device *dev, u8 status)
+{
+ struct sk_buff *msg;
+
+ pr_debug("%s\n", __func__);
+
+ msg = ieee802154_nl_create(0, IEEE802154_START_CONF);
+ if (!msg)
+ return -ENOBUFS;
+
+ NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
+ NLA_PUT_U32(msg, IEEE802154_ATTR_DEV_INDEX, dev->ifindex);
+ NLA_PUT(msg, IEEE802154_ATTR_HW_ADDR, IEEE802154_ADDR_LEN,
+ dev->dev_addr);
+
+ NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS, status);
+
+ return ieee802154_nl_finish(msg);
+
+nla_put_failure:
+ nlmsg_free(msg);
+ return -ENOBUFS;
+}
+EXPORT_SYMBOL(ieee802154_nl_start_confirm);
+
static int ieee802154_nl_fill_iface(struct sk_buff *msg, u32 pid,
u32 seq, int flags, struct net_device *dev)
{
@@ -462,6 +488,12 @@ static int ieee802154_start_req(struct sk_buff *skb, struct genl_info *info)
blx = nla_get_u8(info->attrs[IEEE802154_ATTR_BAT_EXT]);
coord_realign = nla_get_u8(info->attrs[IEEE802154_ATTR_COORD_REALIGN]);
+ if (addr.short_addr == IEEE802154_ADDR_BROADCAST) {
+ ieee802154_nl_start_confirm(dev, IEEE802154_NO_SHORT_ADDRESS);
+ dev_put(dev);
+ return -EINVAL;
+ }
+
ret = ieee802154_mlme_ops(dev)->start_req(dev, &addr, channel,
bcn_ord, sf_ord, pan_coord, blx, coord_realign);
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 10/10] fakehard: use START-CONFIRM primitive to report START failure
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-10-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/ieee802154/fakehard.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/ieee802154/fakehard.c b/drivers/ieee802154/fakehard.c
index 8a52e6e..2bc6c0c 100644
--- a/drivers/ieee802154/fakehard.c
+++ b/drivers/ieee802154/fakehard.c
@@ -177,18 +177,14 @@ static int fake_disassoc_req(struct net_device *dev,
*
* Note: This is in section 7.5.2.3 of the IEEE 802.15.4-2006
* document, with 7.3.8 describing coordinator realignment.
- *
- * Note: There is currently no way to notify the coordinator userland
- * program of whether or not the PAN has started successfully. As
- * such, the coordinator program cannot know when the MAC has
- * completed starting the network and will simply have to assume
- * completeness based on some form of time delay.
*/
static int fake_start_req(struct net_device *dev, struct ieee802154_addr *addr,
u8 channel,
u8 bcn_ord, u8 sf_ord, u8 pan_coord, u8 blx,
u8 coord_realign)
{
+ /* We don't emulate beacons here at all, so START should fail */
+ ieee802154_nl_start_confirm(dev, IEEE802154_INVALID_PARAMETER);
return 0;
}
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 01/10] af_ieee802154: drop IEEE802154_SIOC_ADD_SLAVE declaration
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-1-git-send-email-dbaryshkov@gmail.com>
IEEE802154_SIOC_ADD_SLAVE was used to allocate 802.15.4 interfaces
on the top of radio. It's not used anymore, drop it.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
include/net/af_ieee802154.h | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/net/af_ieee802154.h b/include/net/af_ieee802154.h
index 0d78605..e9c70ea 100644
--- a/include/net/af_ieee802154.h
+++ b/include/net/af_ieee802154.h
@@ -54,7 +54,4 @@ struct sockaddr_ieee802154 {
struct ieee802154_addr addr;
};
-/* master device */
-#define IEEE802154_SIOC_ADD_SLAVE (SIOCDEVPRIVATE + 0)
-
#endif
--
1.6.3.3
^ permalink raw reply related
* [NEXT][GIT PULL 0/10] Updates for the IEEE 802.15.4 stack
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
Please pull in the following updates:
* confirmation for START command
* configurable ACK requests
* other small fixes
^ permalink raw reply
* [PATCH 02/10] af_ieee802154: fix ioctl processing
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-2-git-send-email-dbaryshkov@gmail.com>
fix two errors in ioctl processing:
1) if the ioctl isn't supported one should return -ENOIOCTLCMD
2) don't call ndo_do_ioctl if the device doesn't provide it
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
net/ieee802154/af_ieee802154.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ieee802154/af_ieee802154.c b/net/ieee802154/af_ieee802154.c
index 69c8d92..d504c34 100644
--- a/net/ieee802154/af_ieee802154.c
+++ b/net/ieee802154/af_ieee802154.c
@@ -136,7 +136,7 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
unsigned int cmd)
{
struct ifreq ifr;
- int ret = -EINVAL;
+ int ret = -ENOIOCTLCMD;
struct net_device *dev;
if (copy_from_user(&ifr, arg, sizeof(struct ifreq)))
@@ -146,8 +146,10 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
dev_load(sock_net(sk), ifr.ifr_name);
dev = dev_get_by_name(sock_net(sk), ifr.ifr_name);
- if (dev->type == ARPHRD_IEEE802154 ||
- dev->type == ARPHRD_IEEE802154_PHY)
+
+ if ((dev->type == ARPHRD_IEEE802154 ||
+ dev->type == ARPHRD_IEEE802154_PHY) &&
+ dev->netdev_ops->ndo_do_ioctl)
ret = dev->netdev_ops->ndo_do_ioctl(dev, &ifr, cmd);
if (!ret && copy_to_user(arg, &ifr, sizeof(struct ifreq)))
--
1.6.3.3
^ permalink raw reply related
* [PATCH 03/10] nl802154: make ieee802154_policy constant
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-3-git-send-email-dbaryshkov@gmail.com>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
include/linux/nl802154.h | 2 +-
net/ieee802154/nl_policy.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/nl802154.h b/include/linux/nl802154.h
index 2cda00c..266dd96 100644
--- a/include/linux/nl802154.h
+++ b/include/linux/nl802154.h
@@ -69,7 +69,7 @@ enum {
#define IEEE802154_ATTR_MAX (__IEEE802154_ATTR_MAX - 1)
-extern struct nla_policy ieee802154_policy[];
+extern const struct nla_policy ieee802154_policy[];
/* commands */
/* REQ should be responded with CONF
diff --git a/net/ieee802154/nl_policy.c b/net/ieee802154/nl_policy.c
index c7d71d1..83cb4cc 100644
--- a/net/ieee802154/nl_policy.c
+++ b/net/ieee802154/nl_policy.c
@@ -24,7 +24,7 @@
#define NLA_HW_ADDR NLA_U64
-struct nla_policy ieee802154_policy[IEEE802154_ATTR_MAX + 1] = {
+const struct nla_policy ieee802154_policy[IEEE802154_ATTR_MAX + 1] = {
[IEEE802154_ATTR_DEV_NAME] = { .type = NLA_STRING, },
[IEEE802154_ATTR_DEV_INDEX] = { .type = NLA_U32, },
@@ -50,3 +50,4 @@ struct nla_policy ieee802154_policy[IEEE802154_ATTR_MAX + 1] = {
[IEEE802154_ATTR_DURATION] = { .type = NLA_U8, },
[IEEE802154_ATTR_ED_LIST] = { .len = 27 },
};
+
--
1.6.3.3
^ permalink raw reply related
* [PATCH 04/10] documentation: fix wrt. headers rename
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-4-git-send-email-dbaryshkov@gmail.com>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
Documentation/networking/ieee802154.txt | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 1d4ed66..1c0c82c 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -22,7 +22,7 @@ int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
.....
The address family, socket addresses etc. are defined in the
-include/net/ieee802154/af_ieee802154.h header or in the special header
+include/net/af_ieee802154.h header or in the special header
in our userspace package (see either linux-zigbee sourceforge download page
or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee).
@@ -33,7 +33,7 @@ MLME - MAC Level Management
============================
Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands.
-See the include/net/ieee802154/nl802154.h header. Our userspace tools package
+See the include/net/nl802154.h header. Our userspace tools package
(see above) provides CLI configuration utility for radio interfaces and simple
coordinator for IEEE 802.15.4 networks as an example users of MLME protocol.
@@ -54,7 +54,7 @@ Those types of devices require different approach to be hooked into Linux kernel
HardMAC
=======
-See the header include/net/ieee802154/netdevice.h. You have to implement Linux
+See the header include/net/ieee802154_netdev.h. You have to implement Linux
net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
code via plain sk_buffs. The control block of sk_buffs will contain additional
info as described in the struct ieee802154_mac_cb.
@@ -72,5 +72,4 @@ SoftMAC
We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
in software. This is currently WIP.
-See header include/net/ieee802154/mac802154.h and several drivers in
-drivers/ieee802154/
+See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] be2net: Implementation of request_firmware interface.
From: Ben Hutchings @ 2009-08-07 13:20 UTC (permalink / raw)
To: linuxram; +Cc: Sarveshwar Bandi, netdev, davem
In-Reply-To: <1249636833.6477.812.camel@localhost>
On Fri, 2009-08-07 at 02:20 -0700, Ram Pai wrote:
> On Sun, 2009-07-05 at 15:20 +0100, Ben Hutchings wrote:
> > On Sun, 2009-07-05 at 17:46 +0530, Sarveshwar Bandi wrote:
> > > I understand that most drivers use request_firmware() to load volatile
> > > firmware. I do see that there are other nic drivers that use this inferface to
> > > flash persistent firmware.
> > >
> > > We have other tools for offline flashing; but there is requirement
> > > to flash f/w through driver without having to use other proprietary tools.
> >
> > The firmware blob is proprietary and has to be distributed separately
> > from the kernel. So does it really matter that you have to distribute a
> > special tool as well?
> >
> > (Based on requirements specified by major OEMs, I have implemented
> > firmware update through the sfc driver (MDIO and MTD interfaces) but
> > under the control of a separate tool.)
> >
> > > Since the firmware load happens only when there is a version mismatch with
> > > f/w in /lib/firmware, Users who want to avoid automatic flashing at boot time
> > > can choose not to copy the f/w file under /lib/firmware.
> > [...]
> >
> > Is there a way of loading the firmware into the controller's RAM but not
> > writing it to flash? That ought to be the default behaviour.
> >
>
> Given that the volatile and non-volatile firmware reside in the same
> file, it is not possible for the driver to selectively load the intended
> firmware.
Your design error is your problem.
> However, is this behavior a gating factor for this patch from being
> accepted?
I'm not a gatekeeper; ask David Miller.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] pcnet32: Read buffer overflow
From: Roel Kluin @ 2009-08-07 13:24 UTC (permalink / raw)
To: Don Fry, netdev, Andrew Morton, David S. Miller
An `options[cards_found]' that equals `sizeof(options_mapping)' is already beyond
the array.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/net/pcnet32.c b/drivers/net/pcnet32.c
index 2836815..7f834a3 100644
--- a/drivers/net/pcnet32.c
+++ b/drivers/net/pcnet32.c
@@ -1835,7 +1835,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct pci_dev *pdev)
lp->chip_version = chip_version;
lp->msg_enable = pcnet32_debug;
if ((cards_found >= MAX_UNITS)
- || (options[cards_found] > sizeof(options_mapping)))
+ || (options[cards_found] >= sizeof(options_mapping)))
lp->options = PCNET32_PORT_ASEL;
else
lp->options = options_mapping[options[cards_found]];
^ permalink raw reply related
* Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
From: Anthony Liguori @ 2009-08-07 14:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Gregory Haskins, linux-kernel, alacrityvm-devel, netdev, kvm
In-Reply-To: <20090806081955.GA9752@redhat.com>
Michael S. Tsirkin wrote:
>
>> This series includes the basic plumbing, as well as the driver for
>> accelerated 802.x (ethernet) networking.
>>
>
> The graphs comparing virtio with vbus look interesting.
>
1gbit throughput on a 10gbit link? I have a hard time believing that.
I've seen much higher myself. Can you describe your test setup in more
detail?
Regards,
Anthony Liguori
^ permalink raw reply
* Re: some bug in iproute2
From: jamal @ 2009-08-07 14:28 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Sergey Popov, netdev
In-Reply-To: <20090807101250.GA14064@ff.dom.local>
On Fri, 2009-08-07 at 10:12 +0000, Jarek Poplawski wrote:
> On 06-08-2009 10:50, Sergey Popov wrote:
> If you're using iptables > 1.4.2 then it's a known problem.
> You can read more in a netdev thread:
> Subject: iproute2 action/policer question
> starting date: Tue, 09 Jun 2009 22:10:46 +0200
I am giving up on fixing it for that release for general distros.
I will wait until iptables 1.4.4 becomes mainstream then i will make
another fix. It is very hard to keep up concurently with a) apis
changing randomly on the part of iptables b) distros picking random
versions of iptables and c) iproute2 being released in random
uncoordinated manner.
Maybe a solution that would work is to fork iproute2 or make ipt
part of iptables. In the meantime i can work with anyone who wants
to get it to work with fixed version of iproute2 + iptables. Sergey,
if this is of interest to you let me know.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] lmc: Read outside array bounds
From: Roel Kluin @ 2009-08-07 14:54 UTC (permalink / raw)
To: David S. Miller, khc, netdev, Andrew Morton
In-Reply-To: <20090728144307.c189810b.akpm@linux-foundation.org>
If dev_alloc_skb() fails on the first iteration of the allocation loop, and we
break out of the loop, then we end up writing before the start of the array.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
> First of all, if we allocated at least one buffer we should
> mark the last one in the code right after this loop.
>
> Second of all, we should purge the TX skbs in the next
> loop even if we could not allocate even one RX buffer.
>
> The thing to do is probably to guard the set of "[i-1]" RX ring
> accesses with a "if (i != 0)" check.
Forgot a bit about this one, but I hope this is what you meant?
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c
index 45b1822..b26fabb 100644
--- a/drivers/net/wan/lmc/lmc_main.c
+++ b/drivers/net/wan/lmc/lmc_main.c
@@ -1838,7 +1838,7 @@ void lmc_mii_writereg (lmc_softc_t * const sc, unsigned devaddr, unsigned regno,
static void lmc_softreset (lmc_softc_t * const sc) /*fold00*/
{
- int i;
+ int i, j;
lmc_trace(sc->lmc_device, "lmc_softreset in");
@@ -1897,24 +1897,27 @@ static void lmc_softreset (lmc_softc_t * const sc) /*fold00*/
/*
* Sets end of ring
*/
- sc->lmc_rxring[i - 1].length |= 0x02000000; /* Set end of buffers flag */
- sc->lmc_rxring[i - 1].buffer2 = virt_to_bus (&sc->lmc_rxring[0]); /* Point back to the start */
- LMC_CSR_WRITE (sc, csr_rxlist, virt_to_bus (sc->lmc_rxring)); /* write base address */
+ if (i > 0) {
+ sc->lmc_rxring[i - 1].length |= 0x02000000; /* Set end of buffers flag */
+ sc->lmc_rxring[i - 1].buffer2 = virt_to_bus(&sc->lmc_rxring[0]); /* Point back to the start */
+ LMC_CSR_WRITE(sc, csr_rxlist, virt_to_bus(sc->lmc_rxring)); /* write base address */
+ }
/* Initialize the transmit rings and buffers */
- for (i = 0; i < LMC_TXDESCS; i++)
- {
- if (sc->lmc_txq[i] != NULL){ /* have buffer */
- dev_kfree_skb(sc->lmc_txq[i]); /* free it */
+ for (j = 0; j < i; j++) {
+ if (sc->lmc_txq[j] != NULL) { /* have buffer */
+ dev_kfree_skb(sc->lmc_txq[j]); /* free it */
sc->lmc_device->stats.tx_dropped++; /* We just dropped a packet */
}
- sc->lmc_txq[i] = NULL;
- sc->lmc_txring[i].status = 0x00000000;
- sc->lmc_txring[i].buffer2 = virt_to_bus (&sc->lmc_txring[i + 1]);
+ sc->lmc_txq[j] = NULL;
+ sc->lmc_txring[j].status = 0x00000000;
+ sc->lmc_txring[j].buffer2 = virt_to_bus(&sc->lmc_txring[j + 1]);
+ }
+ if (j > 0) {
+ sc->lmc_txring[j - 1].buffer2 = virt_to_bus(&sc->lmc_txring[0]);
+ LMC_CSR_WRITE(sc, csr_txlist, virt_to_bus(sc->lmc_txring));
}
- sc->lmc_txring[i - 1].buffer2 = virt_to_bus (&sc->lmc_txring[0]);
- LMC_CSR_WRITE (sc, csr_txlist, virt_to_bus (sc->lmc_txring));
lmc_trace(sc->lmc_device, "lmc_softreset out");
}
^ permalink raw reply related
* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Arnd Bergmann @ 2009-08-07 14:57 UTC (permalink / raw)
To: Gregory Haskins; +Cc: alacrityvm-devel, Ira W. Snyder, linux-kernel, netdev
In-Reply-To: <4A7B78580200005A00051D50@sinclair.provo.novell.com>
On Friday 07 August 2009, Gregory Haskins wrote:
> >>> Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 06 August 2009, Gregory Haskins wrote:
> >
> > > 2b) I also want to collapse multiple interrupts together so as to
> > > minimize the context switch rate (inject + EIO overhead). My design
> > > effectively has "NAPI" for interrupt handling. This helps when the system
> > > needs it the most: heavy IO.
> >
> > That sounds like a very useful concept in general, but this seems to be a
> > detail of the interrupt controller implementation. If the IO-APIC cannot
> > do what you want here, maybe we just need a paravirtual IRQ controller
> > driver, like e.g. the PS3 has.
>
> Yeah, I agree this could be a function of the APIC code. Do note that I
> mentioned this in passing to Avi a few months ago but FWIW he indicated
> at that time that he is not interested in making the APIC PV.
>
> Also, I almost forgot an important one. Add:
>
> 2c) Interrupt prioritization. I want to be able to assign priority
> to interrupts and handle them in priority order.
I think this part of the interface has developed into the wrong direction
because you confused two questions:
1. should you build an advanced interrupt mechanism for virtual drivers?
2. how should you build an advanced interrupt mechanism for virtual drivers?
My guess is that when Avi said he did not want a paravirtual IO-APIC,
he implied that the existing one is good enough (maybe Avi can clarify that
point himself) answering question 1, while you took that as an indication
that the code should live elsewhere instead, answering question 2.
What you built with the shm-signal code is essentially a paravirtual nested
interrupt controller by another name, and deeply integrated into a new
bigger subsystem. I believe that this has significant disadvantages
over the approach of making it a standard interrupt controller driver:
* It completely avoids the infrastructure that we have built into Linux
to deal with interrupts, e.g. /proc/interrupts statistics, IRQ
balancing and CPU affinity.
* It makes it impossible to quantify the value of the feature to start with,
which could be used to answer question 1 above.
* Less importantly, it does not work with any other drivers that might
also benefit from a new interrupt controller -- if it is indeed better
than the one we already have.
Arnd <><
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers
From: Gregory Haskins @ 2009-08-07 15:05 UTC (permalink / raw)
To: Anthony Liguori
Cc: Michael S. Tsirkin, Gregory Haskins, linux-kernel,
alacrityvm-devel, netdev, kvm
In-Reply-To: <4A7C37E5.4040302@codemonkey.ws>
[-- Attachment #1: Type: text/plain, Size: 3158 bytes --]
Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>>
>>> This series includes the basic plumbing, as well as the driver for
>>> accelerated 802.x (ethernet) networking.
>>>
>>
>> The graphs comparing virtio with vbus look interesting.
>>
>
> 1gbit throughput on a 10gbit link? I have a hard time believing that.
>
> I've seen much higher myself. Can you describe your test setup in more
> detail?
Sure,
For those graphs, two 8-core x86_64 boxes with Chelsio T3 10GE connected
back to back via cross over with 1500mtu. The kernel version was as
posted. The qemu version was generally something very close to
qemu-kvm.git HEAD at the time the data was gathered, but unfortunately I
didn't seem to log this info.
For KVM, we take one of those boxes and run a bridge+tap configuration
on top of that. We always run the server on the bare-metal machine on
the remote side of the link regardless of whether we run the client in a
VM or baremetal.
For guests, virtio-net and venet connect to the same linux bridge
instance, I just "ifdown eth0 / ifup eth1" (or vice versa) and repeat
the same test. I do this multiple times (usually about 10) and average
the result. I use several different programs, such as netperf, rsync,
and ping to take measurements.
That said, note that the graphs were from earlier kernel runs (2.6.28,
29-rc8). The most recent data I can find that I published is for
2.6.29, announced with the vbus-v3 release back in April:
http://lkml.org/lkml/2009/4/21/408
In it, the virtio-net throughput numbers are substantially higher and
possibly more in line with your expectations (4.5gb/s) (though notably
still lagging venet, which weighed in at 5.6gb/s).
Generally, I find that the virtio-net exhibits non-deterministic results
from release to release. I suspect (as we have discussed) the
tx-mitigation scheme. Some releases buffer the daylights out of the
stream, and virtio gets close(r) throughput (e.g. 4.5g vs 5.8g, but
absolutely terrible latency (4000us vs 65us). Other releases it seems
to operate with more of a compromise (1.3gb/s vs 3.8gb/s, but 350us vs
85us).
I do not understand what causes the virtio performance fluctuation, as I
use the same kernel config across builds, and I do not typically change
the qemu userspace. Note that some general fluctuation is evident
across the board just from kernel to kernel. I am referring to more of
the disparity in throughput vs latency than the ultimate numbers, as all
targets seem to scale max throughput about the same per kernel.
That said, I know I need to redo the graphs against HEAD (31-rc5, and
perhaps 30, and kvm.git). I've been heads down with the eventfd
interfaces since vbus-v3 so I havent been as active with generating the
results. I did confirm that vbus-v4 (alacrityvm-v0.1) still produces a
similar graph, but I didn't gather the data as scientifically as I would
feel comfortable publishing a graph for. This is on the TODO list.
If there is another patch-series/tree I should be using for comparison,
please point me at it.
HTH
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* [PATCH] sctp: fix missing destroy of percpu counter variable in sctp_proc_exit()
From: Vlad Yasevich @ 2009-08-07 15:17 UTC (permalink / raw)
To: netdev; +Cc: davem, Rafael Laufer, Vlad Yasevich
From: Rafael Laufer <rlaufer@cisco.com>
Commit 1748376b6626acf59c24e9592ac67b3fe2a0e026,
net: Use a percpu_counter for sockets_allocated
added percpu_counter function calls to sctp_proc_init code path, but
forgot to add them to sctp_proc_exit(). This resulted in a following
Ooops when performing this test
# modprobe sctp
# rmmod -f sctp
# modprobe sctp
[ 573.862512] BUG: unable to handle kernel paging request at f8214a24
[ 573.862518] IP: [<c0308b8f>] __percpu_counter_init+0x3f/0x70
[ 573.862530] *pde = 37010067 *pte = 00000000
[ 573.862534] Oops: 0002 [#1] SMP
[ 573.862537] last sysfs file: /sys/module/libcrc32c/initstate
[ 573.862540] Modules linked in: sctp(+) crc32c libcrc32c binfmt_misc bridge
stp bnep lp snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep
snd_pcm_oss snd_mixer_oss arc4 joydev snd_pcm ecb pcmcia snd_seq_dummy
snd_seq_oss iwlagn iwlcore snd_seq_midi snd_rawmidi snd_seq_midi_event
yenta_socket rsrc_nonstatic thinkpad_acpi snd_seq snd_timer snd_seq_device
mac80211 psmouse sdhci_pci sdhci nvidia(P) ppdev video snd soundcore serio_raw
pcspkr iTCO_wdt iTCO_vendor_support led_class ricoh_mmc pcmcia_core intel_agp
nvram agpgart usbhid parport_pc parport output snd_page_alloc cfg80211 btusb
ohci1394 ieee1394 e1000e [last unloaded: sctp]
[ 573.862589]
[ 573.862593] Pid: 5373, comm: modprobe Tainted: P R (2.6.31-rc3 #6)
7663B15
[ 573.862596] EIP: 0060:[<c0308b8f>] EFLAGS: 00010286 CPU: 1
[ 573.862599] EIP is at __percpu_counter_init+0x3f/0x70
[ 573.862602] EAX: f8214a20 EBX: f80faa14 ECX: c48c0000 EDX: f80faa20
[ 573.862604] ESI: f80a7000 EDI: 00000000 EBP: f69d5ef0 ESP: f69d5eec
[ 573.862606] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 573.862610] Process modprobe (pid: 5373, ti=f69d4000 task=c2130c70
task.ti=f69d4000)
[ 573.862612] Stack:
[ 573.862613] 00000000 f69d5f18 f80a70a8 f80fa9fc 00000000 fffffffc f69d5f30
c018e2d4
[ 573.862619] <0> 00000000 f80a7000 00000000 f69d5f88 c010112b 00000000
c07029c0 fffffffb
[ 573.862626] <0> 00000000 f69d5f38 c018f83f f69d5f54 c0557cad f80fa860
00000001 c07010c0
[ 573.862634] Call Trace:
[ 573.862644] [<f80a70a8>] ? sctp_init+0xa8/0x7d4 [sctp]
[ 573.862650] [<c018e2d4>] ? marker_update_probe_range+0x184/0x260
[ 573.862659] [<f80a7000>] ? sctp_init+0x0/0x7d4 [sctp]
[ 573.862662] [<c010112b>] ? do_one_initcall+0x2b/0x160
[ 573.862666] [<c018f83f>] ? tracepoint_module_notify+0x2f/0x40
[ 573.862671] [<c0557cad>] ? notifier_call_chain+0x2d/0x70
[ 573.862678] [<c01588fd>] ? __blocking_notifier_call_chain+0x4d/0x60
[ 573.862682] [<c016b2f1>] ? sys_init_module+0xb1/0x1f0
[ 573.862686] [<c0102ffc>] ? sysenter_do_call+0x12/0x28
[ 573.862688] Code: 89 48 08 b8 04 00 00 00 e8 df aa ec ff ba f4 ff ff ff 85
c0 89 43 14 74 31 b8 b0 18 71 c0 e8 19 b9 24 00 a1 c4 18 71 c0 8d 53 0c <89> 50
04 89 43 0c b8 b0 18 71 c0 c7 43 10 c4 18 71 c0 89 15 c4
[ 573.862725] EIP: [<c0308b8f>] __percpu_counter_init+0x3f/0x70 SS:ESP
0068:f69d5eec
[ 573.862730] CR2: 00000000f8214a24
[ 573.862734] ---[ end trace 39c4e0b55e7cf54d ]---
Signed-off-by: Rafael Laufer <rlaufer@cisco.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
---
net/sctp/protocol.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 79cbd47..a76da65 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -160,6 +160,7 @@ static void sctp_proc_exit(void)
remove_proc_entry("sctp", init_net.proc_net);
}
#endif
+ percpu_counter_destroy(&sctp_sockets_allocated);
}
/* Private helper to extract ipv4 address and stash them in
--
1.5.4.3
^ permalink raw reply related
* [PATCH] korina: Read buffer overflow
From: Roel Kluin @ 2009-08-07 15:33 UTC (permalink / raw)
To: netdev, Andrew Morton, David S. Miller, n0-1, florian
If the loop breaks with an i of 0, then we read lp->rd_ring[-1].
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Should we clean up like this? please review
diff --git a/drivers/net/korina.c b/drivers/net/korina.c
index b4cf602..b965b2b 100644
--- a/drivers/net/korina.c
+++ b/drivers/net/korina.c
@@ -754,7 +754,7 @@ static void korina_alloc_ring(struct net_device *dev)
{
struct korina_private *lp = netdev_priv(dev);
struct sk_buff *skb;
- int i;
+ int i, j;
/* Initialize the transmit descriptors */
for (i = 0; i < KORINA_NUM_TDS; i++) {
@@ -771,7 +771,7 @@ static void korina_alloc_ring(struct net_device *dev)
for (i = 0; i < KORINA_NUM_RDS; i++) {
skb = dev_alloc_skb(KORINA_RBSIZE + 2);
if (!skb)
- break;
+ goto err_free;
skb_reserve(skb, 2);
lp->rx_skb[i] = skb;
lp->rd_ring[i].control = DMA_DESC_IOD |
@@ -790,6 +790,12 @@ static void korina_alloc_ring(struct net_device *dev)
lp->rx_chain_head = 0;
lp->rx_chain_tail = 0;
lp->rx_chain_status = desc_empty;
+err_free:
+ for (j = 0; j < i; j++) {
+ lp->rd_ring[j].control = 0;
+ dev_kfree_skb_any(lp->rx_skb[j]);
+ lp->rx_skb[j] = NULL;
+ }
}
static void korina_free_ring(struct net_device *dev)
^ permalink raw reply related
* Re: [PATCH 2/7 v3] initdev:kernel:USB init device discovery notification
From: Alan Jenkins @ 2009-08-07 15:32 UTC (permalink / raw)
To: David VomLehn
Cc: linux-kernel, akpm, linux-usb, greg, linux-scsi, netdev, arjan
In-Reply-To: <20090804221506.GA9256@cuplxvomd02.corp.sa.net>
On 8/4/09, David VomLehn <dvomlehn@cisco.com> wrote:
> From: Alan Stern <stern@rowland.harvard.edu>
>
> Use init device discovery infrastructure to provide notification of
> availability of USB devices.
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> Signed-off-by: David VomLehn <dvomlehn@cisco.com>
> ---
> drivers/usb/core/hub.c | 26 ++++++++++++++++++++++++++
> 1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index be86ae3..08baee0 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -37,6 +37,20 @@
> #endif
> #endif
>
> +/* The mask of possible USB boot devices depends on what drivers and
> + * options have been configured into the kernel. There are too many
> + * USB network config options to list here, so just assume it is always
> + * possible to have a USB network device.
> + */
That could be fixed though. Make the "USB Network Adaptors" menu into
an option. Then you just have e.g. "CONFIG_NETDEV_USB", plus the two
class devices outside the menu (CONFIG_USB_ACM and CONFIG_USB_WDM).
Alan
^ permalink raw reply
* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Gregory Haskins @ 2009-08-07 15:44 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: alacrityvm-devel, Ira W. Snyder, linux-kernel, netdev
In-Reply-To: <200908071657.32858.arnd@arndb.de>
>>> On 8/7/2009 at 10:57 AM, in message <200908071657.32858.arnd@arndb.de>, Arnd
Bergmann <arnd@arndb.de> wrote:
> On Friday 07 August 2009, Gregory Haskins wrote:
>> >>> Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Thursday 06 August 2009, Gregory Haskins wrote:
>> >
>> > > 2b) I also want to collapse multiple interrupts together so as to
>> > > minimize the context switch rate (inject + EIO overhead). My design
>> > > effectively has "NAPI" for interrupt handling. This helps when the system
>
>> > > needs it the most: heavy IO.
>> >
>> > That sounds like a very useful concept in general, but this seems to be a
>> > detail of the interrupt controller implementation. If the IO-APIC cannot
>> > do what you want here, maybe we just need a paravirtual IRQ controller
>> > driver, like e.g. the PS3 has.
>>
>> Yeah, I agree this could be a function of the APIC code. Do note that I
>> mentioned this in passing to Avi a few months ago but FWIW he indicated
>> at that time that he is not interested in making the APIC PV.
>>
>> Also, I almost forgot an important one. Add:
>>
>> 2c) Interrupt prioritization. I want to be able to assign priority
>> to interrupts and handle them in priority order.
>
> I think this part of the interface has developed into the wrong direction
> because you confused two questions:
>
> 1. should you build an advanced interrupt mechanism for virtual drivers?
> 2. how should you build an advanced interrupt mechanism for virtual drivers?
>
> My guess is that when Avi said he did not want a paravirtual IO-APIC,
> he implied that the existing one is good enough (maybe Avi can clarify that
> point himself) answering question 1, while you took that as an indication
> that the code should live elsewhere instead, answering question 2.
>
> What you built with the shm-signal code is essentially a paravirtual nested
> interrupt controller by another name, and deeply integrated into a new
> bigger subsystem. I believe that this has significant disadvantages
> over the approach of making it a standard interrupt controller driver:
>
> * It completely avoids the infrastructure that we have built into Linux
> to deal with interrupts, e.g. /proc/interrupts statistics, IRQ
> balancing and CPU affinity.
>
> * It makes it impossible to quantify the value of the feature to start with,
> which could be used to answer question 1 above.
>
> * Less importantly, it does not work with any other drivers that might
> also benefit from a new interrupt controller -- if it is indeed better
> than the one we already have.
>
> Arnd <><
Hi Arnd,
I don't strongly disagree with anything you said (except for perhaps that I confused the question). I agree that the PCI-bridge effectively implements something akin to an interrupt controller. I agree that this interrupt controller, if indeed superior (I believe it is), can only benefit devices inherently behind the bridge instead of all of KVM (this in of itself doesnt bother me, as I plan on all my performance work to be based on that bus, but I digress. Also note that this is not dissimilar to other bridge+bus (think usb, scsi) operation). I agree that a potentially more ideal solution would be if we had a proper generic PV interrupt controller that exhibited similar traits as to what I describe (priority, inject+EIO overhead reduction, etc) so that all of KVM benefited.
The issue wasn't that I didn't know these things. The issue is that I have no control over whether such an intrusive change to KVM (and the guest arch code) is accepted (and at least one relevant maintainer expressed dissatisfaction (*) at the idea when proposed) Conversely, I am the maintainer of AlacrityVM, so I do have control over the bridge design. ;) Also note that this particular design decision is completely encapsulated within alacrityvm's components. IOW, I am not foisting my ideas on the entire kernel tree: If someone doesn't like what I have done, they can choose not to use alacrity and its like my ideas never existed. The important thing with this distinction is I am not changing how core linux or core kvm works in the process, only the one little piece of the world that
particularly interests me.
That said, if attitudes about some of these ideas have changed, I may be able to break that piece out and start submitting it to kvm@ as some kind of pv interrupt controller. I would only be interested in doing so if Avi et. al. express an openness to the idea...I.e.. I don't want to waste my time any more than any one elses.
Kind Regards,
-Greg
(*) I think Avi said something to the effect of "you are falling into the 'lets PV the world' trap"
^ permalink raw reply
* Re: [PATCH 2/7 v3] initdev:kernel:USB init device discovery notification
From: Alan Stern @ 2009-08-07 15:44 UTC (permalink / raw)
To: Alan Jenkins
Cc: David VomLehn, linux-kernel, akpm, linux-usb, greg, linux-scsi,
netdev, arjan
In-Reply-To: <9b2b86520908070832p2d1658b0t8b1d89d1a034bb9a@mail.gmail.com>
On Fri, 7 Aug 2009, Alan Jenkins wrote:
> > +/* The mask of possible USB boot devices depends on what drivers and
> > + * options have been configured into the kernel. There are too many
> > + * USB network config options to list here, so just assume it is always
> > + * possible to have a USB network device.
> > + */
>
> That could be fixed though. Make the "USB Network Adaptors" menu into
> an option. Then you just have e.g. "CONFIG_NETDEV_USB", plus the two
> class devices outside the menu (CONFIG_USB_ACM and CONFIG_USB_WDM).
That could be done. It might even meet with the approval of the
networking maintainer, independent of this patch series.
But what if somebody adds yet another networking class driver outside
the menu?
Alan Stern
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers
From: Anthony Liguori @ 2009-08-07 15:46 UTC (permalink / raw)
To: Gregory Haskins
Cc: Michael S. Tsirkin, Gregory Haskins, linux-kernel,
alacrityvm-devel, netdev, kvm
In-Reply-To: <4A7C42C8.5050608@gmail.com>
Gregory Haskins wrote:
> That said, note that the graphs were from earlier kernel runs (2.6.28,
> 29-rc8). The most recent data I can find that I published is for
> 2.6.29, announced with the vbus-v3 release back in April:
>
> http://lkml.org/lkml/2009/4/21/408
>
> In it, the virtio-net throughput numbers are substantially higher and
> possibly more in line with your expectations (4.5gb/s) (though notably
> still lagging venet, which weighed in at 5.6gb/s).
>
Okay, that makes more sense. Would be nice to update the graphs as they
make virtio look really, really bad :-)
> Generally, I find that the virtio-net exhibits non-deterministic results
> from release to release. I suspect (as we have discussed) the
> tx-mitigation scheme. Some releases buffer the daylights out of the
> stream, and virtio gets close(r) throughput (e.g. 4.5g vs 5.8g, but
> absolutely terrible latency (4000us vs 65us). Other releases it seems
> to operate with more of a compromise (1.3gb/s vs 3.8gb/s, but 350us vs
> 85us).
>
Are you using kvm modules or a new kernel? There was some timer
infrastructure changes around 28/29 and it's possible that the system
your on is now detecting an hpet which will result in a better time
source. That could have an affect on mitigation.
> If there is another patch-series/tree I should be using for comparison,
> please point me at it.
>
No, I think it's fair to look at upstream Linux. Looking at the latest
bits would be nice though because there are some virtio friendly changes
recently like MSI-x and GRO.
Since you're using the latest vbus bits, it makes sense to compare
against the latest virtio bits.
Regards,
Anthony Liguori
^ permalink raw reply
* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Ira W. Snyder @ 2009-08-07 15:55 UTC (permalink / raw)
To: Gregory Haskins; +Cc: Arnd Bergmann, alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <4A7B78580200005A00051D50@sinclair.provo.novell.com>
On Thu, Aug 06, 2009 at 10:42:00PM -0600, Gregory Haskins wrote:
> >>> On 8/6/2009 at 6:57 PM, in message <200908070057.54795.arnd@arndb.de>, Arnd
> Bergmann <arnd@arndb.de> wrote:
[ big snip ]
> >> I see a few issues with that, however:
> >>
> >> 1) The virtqueue library, while a perfectly nice ring design at the metadata
> > level, does not have an API that is friendly to kernel-to-kernel communication.
> > It was designed more for frontend use to some remote backend. The IOQ
> > library on the other hand, was specifically designed to support use as
> > kernel-to-kernel (see north/south designations). So this made life easier
> > for me. To do what you propose, the eventq channel would need to terminate
> > in kernel, and I would thus be forced to deal that the potential API
> > problems.
> >
> > Well, virtqueues are not that bad for kernel-to-kernel communication, as Ira
> > mentioned
> > referring to his virtio-over-PCI driver. You can have virtqueues on both
> > sides, having
> > the host kernel create a pair of virtqueues (one in user aka guest space,
> > one in the host
> > kernel), with the host virtqueue_ops doing copy_{to,from}_user to move data
> > between them.
>
> Its been a while since I looked, so perhaps I am wrong here. I will look again.
>
> >
> > If you have that, you can actually use the same virtio_net driver in both
> > guest and
> > host kernel, just communicating over different virtio implementations.
> > Interestingly,
> > that would mean that you no longer need a separation between guest and host
> > device
> > drivers (vbus and vbus-proxy in your case) but could use the same device
> > abstraction
> > with just different transports to back the shm-signal or virtqueue.
>
> Actually, I think there are some problems with that model (such as management of the interface). virtio-net really wants to connect to a virtio-net-backend (such as the one in qemu or vbus). It wasn't designed to connect back to back like that. I think you will quickly run into problems similar to what Ira faced with virtio-over-PCI with that model.
>
Getting the virtio-net devices talking to each other over PCI was not
terribly difficult. However, the capabilities negotiation works in a
VERY awkward way. The capabilities negotiation was really designed with
a virtio-net-backend in mind. Unless I'm missing something obvious, it
is essentially broken for the case where two virtio-net's are talking to
each other.
For example, imagine the situation where you'd like the guest to get a
specific MAC address, but you do not care what MAC address the host
recieves.
Normally, you'd set struct virtio_net_config's mac[] field, and set the
VIRTIO_NET_F_MAC feature. However, when you have two virtio-net's
communicating directly, this doesn't work.
Let me explain with a quick diagram. The results described are the
values RETURNED from virtio_config_ops->get() and
virtio_config_ops->get_features() when called by the system in question.
Guest System
1) struct virtio_net_config->mac[]: 00:11:22:33:44:55
2) features: VIRTIO_NET_F_MAC
Host System
1) struct virtio_net_config->mac[]: unset
2) features: VIRTIO_NET_F_MAC unset
In this case, the feature negotiation code will not accept the
VIRTIO_NET_F_MAC feature, and both systems will generate random mac
addresses. Not the behavior we want at all.
I "fixed" the problem by ALWAYS setting a random MAC address, and ALWAYS
setting the VIRTIO_NET_F_MAC feature. By doing this, both sides always
negotiate the VIRTIO_NET_F_MAC feature.
In conclusion, the feature negotiation works fine for driver features,
such as VIRTIO_NET_MRG_RXBUF or VIRTIO_NET_F_GSO, but completely breaks
down for user-controlled features, like VIRTIO_NET_F_MAC.
I think the vbus configfs interface works great for this situation,
because it has an obvious and seperate backend. It is obvious where the
configuration information is coming from.
With my powerpc hardware, it should be easily possible to have at least
6 devices, each with two virtqueues, one for tx and one for rx. (The
limit is caused by the amount of distinct kick() events I can generate.)
This could allow many combinations of devices, such as:
* 1 virtio-net, 1 virtio-console
* 3 virtio-net, 2 virtio-console
* 6 virtio-net
* etc.
In all honesty, I don't really care so much about the management
interface for my purposes. A static configuration of devices works for
me. However, I doubt that would ever be accepted into the upstream
kernel, which is what I'm really concerned about. I hate seeing drivers
live out-of-tree.
Getting two virtio-net's talking to each other had one other major
problem: the fields in struct virtio_net_hdr are not defined with a
constant endianness. When connecting two virtio-net's running on
different machines, they may have different endianness, as in my case
between a big-endian powerpc guest and a little-endian x86 host. I'm not
confident that qemu-system-ppc, running on x86, using virtio for the
network interface, even works at all. (I have not tested it.)
Sorry that this got somewhat long winded and went a little off topic.
Ira
^ permalink raw reply
* Re: 3x59x-fix-pci-resource-management.patch
From: Andrew Morton @ 2009-08-07 16:14 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Steffen Klassert, netdev
In-Reply-To: <4A7C079D.8010505@ru.mvista.com>
On Fri, 07 Aug 2009 14:53:17 +0400 Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> Hello.
>
> Andrew Morton wrote:
>
> > Guys, I seem to have been sitting on the below patch for, err, three years.
>
> > I generally do this because there's some issue which needs to be
> > addressed, but the patch didn't address it right.
>
> In this case it was different: you just wanted the patch to be verifed
> on an EISA card...
>
> On Mon, 14 Aug 2006 14:31:46 -0400
> Jeff Garzik <jgarzik@pobox.com> wrote:
>
> >> ACK, shall I apply this to netdev#upstream ?
>
> Spose so, but let's not go mainline until I've had a chance to test an
> EISA card and a cardbus card.
>
> There was several more comments from you but they all got resolved
> between you and Jeff at the time...
>
Doh, OK, thanks. My fault.
I have a cardbus card somewhere..
^ permalink raw reply
* [PATCH] MAINTAINERS: additional NETWORKING [GENERAL] and NETWORKING DRIVERS patterns
From: Joe Perches @ 2009-08-07 16:43 UTC (permalink / raw)
To: David Miller; +Cc: sposelenov, linux-kernel, wd, netdev, Andrew Morton
In-Reply-To: <20090807.090353.191304972.davem@davemloft.net>
On Fri, 2009-08-07 at 09:03 -0700, David Miller wrote:
> From: Sergei Poselenov <sposelenov@emcraft.com>
> > Unfortunately, received no replies, but the problem still persists.
> I guarantee you'll get more responses if you send networking bug
> reports at least CC:'d to netdev@vger.kernel.org
Perhaps this will help get cc's to the right places.
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index b1114cf..0b697a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3555,6 +3555,9 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
S: Maintained
F: net/
F: include/net/
+F: include/linux/in.h
+F: include/linux/net.h
+F: include/linux/netdevice.h
NETWORKING [IPv4/IPv6]
M: "David S. Miller" <davem@davemloft.net>
@@ -3590,6 +3593,8 @@ W: http://www.linuxfoundation.org/en/Net
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
S: Odd Fixes
F: drivers/net/
+F: include/linux/if_*
+F: include/linux/*device.h
NETXEN (1/10) GbE SUPPORT
M: Dhananjay Phadke <dhananjay@netxen.com>
^ permalink raw reply related
* [PATCH] REPORTING-BUGS: Add get_maintainer.pl blurb
From: Joe Perches @ 2009-08-07 17:01 UTC (permalink / raw)
To: David Miller; +Cc: sposelenov, linux-kernel, Andrew Morton, netdev
In-Reply-To: <20090807.090353.191304972.davem@davemloft.net>
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/REPORTING-BUGS b/REPORTING-BUGS
index ab0c566..55a6074 100644
--- a/REPORTING-BUGS
+++ b/REPORTING-BUGS
@@ -15,7 +15,10 @@ worry too much about getting the wrong person. If you are unsure send it
to the person responsible for the code relevant to what you were doing.
If it occurs repeatably try and describe how to recreate it. That is
worth even more than the oops itself. The list of maintainers and
-mailing lists is in the MAINTAINERS file in this directory.
+mailing lists is in the MAINTAINERS file in this directory. If you
+know the file name that causes the problem you can use the following
+command in this directory to find some of the maintainers of that file:
+ perl scripts/get_maintainer.pl -f <filename>
If it is a security bug, please copy the Security Contact listed
in the MAINTAINERS file. They can help coordinate bugfix and disclosure.
^ permalink raw reply related
* Re: [PATCH 2/7 v3] initdev:kernel:USB init device discovery notification
From: Alan Jenkins @ 2009-08-07 17:17 UTC (permalink / raw)
To: Alan Stern
Cc: David VomLehn, linux-kernel, akpm, linux-usb, greg, linux-scsi,
netdev, arjan
In-Reply-To: <Pine.LNX.4.44L0.0908071142260.3063-100000@iolanthe.rowland.org>
On 8/7/09, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 7 Aug 2009, Alan Jenkins wrote:
>
>> > +/* The mask of possible USB boot devices depends on what drivers and
>> > + * options have been configured into the kernel. There are too many
>> > + * USB network config options to list here, so just assume it is always
>> > + * possible to have a USB network device.
>> > + */
>>
>> That could be fixed though. Make the "USB Network Adaptors" menu into
>> an option. Then you just have e.g. "CONFIG_NETDEV_USB", plus the two
>> class devices outside the menu (CONFIG_USB_ACM and CONFIG_USB_WDM).
Oops, scratch WDM. It doesn't actually provide a network device
(otherwise it would depend on NET).
> That could be done. It might even meet with the approval of the
> networking maintainer, independent of this patch series.
>
> But what if somebody adds yet another networking class driver outside
> the menu?
Hmm.
Ok, how about a single (hidden) USB_HAS_NETDEV. NETDEV_USB and
USB_ACM select USB_HAS_NETDEV.
Textual juxtaposition or simple copy+paste inside class/Kconfig should
help it get picked up. And I'd add a comment pointing the bewildered
to the definition of usb_initdev_mask.
I'll write a patch for your inspection this evening.
Alan
^ 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