* Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
From: Karl Meyer @ 2007-09-26 9:07 UTC (permalink / raw)
To: Francois Romieu; +Cc: Michal Piotrowski, linux-kernel, netdev
In-Reply-To: <20070912205025.GA31709@electric-eye.fr.zoreil.com>
Hi Francois,
this is what I found and sent:
The error exists from patch 2 on. I did some network testing with
patch 1 and currently use it and have no errors so far.
>From my experiences up to now patch 1 should be error free.
Do you need additional info?
2007/9/12, Francois Romieu <romieu@fr.zoreil.com>:
> Karl Meyer <adhocrocker@gmail.com> :
> [...]
> > am am looking for this issue for some time now, but there where no
> > errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2
> > officially), I also ran git-bisect (for more information see the older
> > messages in this thread).
>
> 2.6.22-r2 in gentoo is based on 2.6.22.1. It is way before
> 0e4851502f846b13b29b7f88f1250c980d57e944 that you reported to work.
> Thus it is not surprizing that it works.
>
> Any update regarding the patchkit that I sent on 2007/08/16 ?
>
> It would help to narrow the culprit.
>
> --
> Ueimor
>
^ permalink raw reply
* Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
From: FUJITA Tomonori @ 2007-09-26 8:57 UTC (permalink / raw)
To: hare
Cc: tomof, open-iscsi, hch, jeff, davem, mchristi, netdev, anilgv,
talm, lusinsky, uri, fujita.tomonori
In-Reply-To: <46F8C935.8050907@suse.de>
On Tue, 25 Sep 2007 10:39:17 +0200
Hannes Reinecke <hare@suse.de> wrote:
> Hi Tomo,
>
> FUJITA Tomonori wrote:
> > On Sat, 8 Sep 2007 13:00:36 +0100
> > Christoph Hellwig <hch@infradead.org> wrote:
> >
> >> On Sat, Sep 08, 2007 at 07:32:27AM -0400, Jeff Garzik wrote:
> >>> FUJITA Tomonori wrote:
> >>>> Yeah, iommu code ignores the lld limitations (the problem is that the
> >>>> lld limitations are in request_queue and iommu code can't access to
> >>>> request_queue). There is no way to tell iommu code about the lld
> >>>> limitations.
> >>>
> >>> This fact very much wants fixing.
> >>
> >> Absolutely. Unfortunately everyone wastes their time on creating workarounds
> >> instead of fixing the underlying problem.
> >
> > Any ideas on how to fix this?
> >
> > I chatted to Jens and James on this last week.
> >
> > - we could just copies the lld limitations to device structure. it's
> > hacky but device structure already has hacky stuff.
> >
> > - we could just link device structure to request_queue structure so
> > that iommu code can see request_queue structure.
> >
> > - we could remove the lld limitations in request_queue strucutre and
> > have a new strucutre (something like struct io_restrictions). then
> > somehow we could link the new structure with request_queue and device
> > strucutres.
> >
> I'd prefer the latter. These struct io_restrictions could then be used
> by dm (which has it's own version right now) to merge queue capabilities.
Yeah, we could nicely handle lld's restrictions (especially with
stacking devices). But iommu code needs only max_segment_size and
seg_boundary_mask, right? If so, the first simple approach to add two
values to device structure is not so bad, I think.
^ permalink raw reply
* Re: Userspace network stack and netchannels.
From: Evgeniy Polyakov @ 2007-09-26 8:53 UTC (permalink / raw)
To: Robert Iakobashvili; +Cc: netdev
In-Reply-To: <7e63f56c0709251220s12ab10b5pade5b2c90fa4a8b9@mail.gmail.com>
Hi Robert.
On Tue, Sep 25, 2007 at 09:20:44PM +0200, Robert Iakobashvili (coroberti@gmail.com) wrote:
> > 3. Gigabit send/recv benchmark for netchannels and sockets using small
> > packets.
> > http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_10_26.html
> > http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_12_21.html
> >
>
> Very interesting. Are there any details of your benchmarking available,
> namely, how it was done?
> Have you some comparison profiling data (oprofile) to figure out where
> the advantages are coming from?
Those are throughput tests - one sender, one receiver with different
size of the packet being sent/received. CPU usage was determined via
/proc statistics. My analysis says that reduced number of syscalls is
main improvement factor, but different (non-rfc-compliant) congestion
control allows faster start and faster recovery.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: Userspace network stack and netchannels.
From: Evgeniy Polyakov @ 2007-09-26 8:47 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20070925123444.10346e99@freepuppy.rosehill>
On Tue, Sep 25, 2007 at 12:34:44PM -0700, Stephen Hemminger (shemminger@linux-foundation.org) wrote:
> > It was proven [3] that unetstack can be *much* faster than vanilla TCP
> > stack (mainly because of heavily reduced number of syscalls, different
> > congestion control algorithm and other features).
>
> I am glad to see a more complete implementation for comparison, but
> by changing several variables at once it makes it hard to evaluate whether
> the improvement comes from user space TCP or the other changes.
Number of issues were improved - mostly reduced number of syscalls (if
size of the message increases results become essentially the same).
Different (non-rfc-compliant) congestion control algorithm allows faster
start and recovery, but in slower links (or longer rtt) it can be wrong.
Originally it was created to show superiority of the netchannel architecture,
but several hundreds of percents in some cases is not result of
peer-to-peer and process context processing. This stack works with
netchannels, which just became a link between hardware and user, such
approach allows huge variety of usage for different network hardware
including safe offloading, sniffing and so on. This stack is an example.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: net-2.6.24 rebased...
From: Johannes Berg @ 2007-09-26 7:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linville, jeff, akpm
In-Reply-To: <20070925.233344.43202361.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
On Tue, 2007-09-25 at 23:33 -0700, David Miller wrote:
> http://vger.kernel.org/~davem/0433-Z1211-Fix-TX-status-reports.patch
>
> What probably needs to happen is some other changes that
> were in z1211 need to go into the non-mac80211 driver and
> then this patch applies correctly.
>
> I tried the simple thing to rename the directory in the patch
> and that didn't work, obviously :-)
That patch is specific to the mac80211 version and you don't have that
yet, it just needs to be stick along with it till the next time.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* [patch 33/43] lguest: Net driver using virtio
From: rusty @ 2007-09-26 6:36 UTC (permalink / raw)
To: lguest; +Cc: virtualization, Christian Borntraeger, Herbert Xu, netdev
In-Reply-To: <20070926063618.956228976@rustcorp.com.au>
[-- Attachment #1: new-io-net.patch --]
[-- Type: text/plain, Size: 14981 bytes --]
The network driver uses two virtqueues: one for input packets and one
for output packets. This has nice locking properties (ie. we don't do
any for recv vs send).
TODO:
1) Big packets.
2) Multi-client devices (maybe separate driver?).
3) Resolve freeing of old xmit skbs (Christian Borntraeger)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: netdev@vger.kernel.org
---
drivers/net/Kconfig | 6
drivers/net/Makefile | 2
drivers/net/virtio_net.c | 438 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/virtio_net.h | 36 +++
4 files changed, 481 insertions(+), 1 deletion(-)
===================================================================
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2998,4 +2998,10 @@ config NET_POLL_CONTROLLER
config NET_POLL_CONTROLLER
def_bool NETPOLL
+config VIRTIO_NET
+ tristate "Virtio network driver (EXPERIMENTAL)"
+ depends on EXPERIMENTAL && VIRTIO
+ ---help---
+ This is the virtual network driver for lguest. Say Y or M.
+
endif # NETDEVICES
===================================================================
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -38,7 +38,7 @@ obj-$(CONFIG_SUNVNET) += sunvnet.o
obj-$(CONFIG_MACE) += mace.o
obj-$(CONFIG_BMAC) += bmac.o
-
+obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
obj-$(CONFIG_DGRS) += dgrs.o
obj-$(CONFIG_VORTEX) += 3c59x.o
obj-$(CONFIG_TYPHOON) += typhoon.o
===================================================================
--- /dev/null
+++ b/drivers/net/virtio_net.c
@@ -0,0 +1,438 @@
+/* A simple network driver using virtio.
+ *
+ * Copyright 2007 Rusty Russell <rusty@rustcorp.com.au> IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+//#define DEBUG
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/module.h>
+#include <linux/virtio.h>
+#include <linux/virtio_net.h>
+#include <linux/scatterlist.h>
+
+/* FIXME: MTU in config. */
+#define MAX_PACKET_LEN (ETH_HLEN+ETH_DATA_LEN)
+
+struct virtnet_info
+{
+ struct virtio_device *vdev;
+ struct virtqueue *rvq, *svq;
+ struct net_device *dev;
+
+ /* Number of input buffers, and max we've ever had. */
+ unsigned int num, max;
+
+ /* Receive & send queues. */
+ struct sk_buff_head recv;
+ struct sk_buff_head send;
+};
+
+static inline struct virtio_net_hdr *skb_vnet_hdr(struct sk_buff *skb)
+{
+ return (struct virtio_net_hdr *)skb->cb;
+}
+
+static inline void vnet_hdr_to_sg(struct scatterlist *sg, struct sk_buff *skb)
+{
+ sg_init_one(sg, skb_vnet_hdr(skb), sizeof(struct virtio_net_hdr));
+}
+
+static bool skb_xmit_done(struct virtqueue *rvq)
+{
+ struct virtnet_info *vi = rvq->vdev->priv;
+
+ /* In case we were waiting for output buffers. */
+ netif_wake_queue(vi->dev);
+ return true;
+}
+
+static void receive_skb(struct net_device *dev, struct sk_buff *skb,
+ unsigned len)
+{
+ struct virtio_net_hdr *hdr = skb_vnet_hdr(skb);
+
+ if (unlikely(len < sizeof(struct virtio_net_hdr) + ETH_HLEN)) {
+ pr_debug("%s: short packet %i\n", dev->name, len);
+ dev->stats.rx_length_errors++;
+ goto drop;
+ }
+ len -= sizeof(struct virtio_net_hdr);
+ BUG_ON(len > MAX_PACKET_LEN);
+
+ skb_trim(skb, len);
+ skb->protocol = eth_type_trans(skb, dev);
+ pr_debug("Receiving skb proto 0x%04x len %i type %i\n",
+ ntohs(skb->protocol), skb->len, skb->pkt_type);
+ dev->stats.rx_bytes += skb->len;
+ dev->stats.rx_packets++;
+
+ if (hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
+ pr_debug("Needs csum!\n");
+ skb->ip_summed = CHECKSUM_PARTIAL;
+ skb->csum_start = hdr->csum_start;
+ skb->csum_offset = hdr->csum_offset;
+ if (skb->csum_start > skb->len - 2
+ || skb->csum_offset > skb->len - 2) {
+ if (net_ratelimit())
+ printk(KERN_WARNING "%s: csum=%u/%u len=%u\n",
+ dev->name, skb->csum_start,
+ skb->csum_offset, skb->len);
+ goto frame_err;
+ }
+ }
+
+ if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
+ pr_debug("GSO!\n");
+ switch (hdr->gso_type) {
+ case VIRTIO_NET_HDR_GSO_TCPV4:
+ skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
+ break;
+ case VIRTIO_NET_HDR_GSO_TCPV4_ECN:
+ skb_shinfo(skb)->gso_type = SKB_GSO_TCP_ECN;
+ break;
+ case VIRTIO_NET_HDR_GSO_UDP:
+ skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
+ break;
+ case VIRTIO_NET_HDR_GSO_TCPV6:
+ skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
+ break;
+ default:
+ if (net_ratelimit())
+ printk(KERN_WARNING "%s: bad gso type %u.\n",
+ dev->name, hdr->gso_type);
+ goto frame_err;
+ }
+
+ skb_shinfo(skb)->gso_size = hdr->gso_size;
+ if (skb_shinfo(skb)->gso_size == 0) {
+ if (net_ratelimit())
+ printk(KERN_WARNING "%s: zero gso size.\n",
+ dev->name);
+ goto frame_err;
+ }
+
+ /* Header must be checked, and gso_segs computed. */
+ skb_shinfo(skb)->gso_type |= SKB_GSO_DODGY;
+ skb_shinfo(skb)->gso_segs = 0;
+ }
+
+ netif_receive_skb(skb);
+ return;
+
+frame_err:
+ dev->stats.rx_frame_errors++;
+drop:
+ dev_kfree_skb(skb);
+}
+
+static void try_fill_recv(struct virtnet_info *vi)
+{
+ struct sk_buff *skb;
+ struct scatterlist sg[1+MAX_SKB_FRAGS];
+ int num, err;
+
+ for (;;) {
+ skb = netdev_alloc_skb(vi->dev, MAX_PACKET_LEN);
+ if (unlikely(!skb))
+ break;
+
+ skb_put(skb, MAX_PACKET_LEN);
+ vnet_hdr_to_sg(sg, skb);
+ num = skb_to_sgvec(skb, sg+1, 0, skb->len) + 1;
+ skb_queue_head(&vi->recv, skb);
+
+ err = vi->rvq->vq_ops->add_buf(vi->rvq, sg, 0, num, skb);
+ if (err) {
+ skb_unlink(skb, &vi->recv);
+ kfree_skb(skb);
+ break;
+ }
+ vi->num++;
+ }
+ if (unlikely(vi->num > vi->max))
+ vi->max = vi->num;
+ vi->rvq->vq_ops->kick(vi->rvq);
+}
+
+static bool skb_recv_done(struct virtqueue *rvq)
+{
+ struct virtnet_info *vi = rvq->vdev->priv;
+ netif_rx_schedule(vi->dev);
+ /* Suppress further interrupts. */
+ return false;
+}
+
+static int virtnet_poll(struct net_device *dev, int *budget)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct sk_buff *skb = NULL;
+ unsigned int len, received = 0;
+
+again:
+ while (received < dev->quota &&
+ (skb = vi->rvq->vq_ops->get_buf(vi->rvq, &len)) != NULL) {
+ __skb_unlink(skb, &vi->recv);
+ receive_skb(vi->dev, skb, len);
+ vi->num--;
+ received++;
+ }
+
+ dev->quota -= received;
+ *budget -= received;
+
+ /* FIXME: If we oom and completely run out of inbufs, we need
+ * to start a timer trying to fill more. */
+ if (vi->num < vi->max / 2)
+ try_fill_recv(vi);
+
+ /* Still more work to do? */
+ if (skb)
+ return 1; /* not done */
+
+ netif_rx_complete(dev);
+ if (unlikely(!vi->rvq->vq_ops->restart(vi->rvq))
+ && netif_rx_reschedule(dev, received))
+ goto again;
+
+ return 0;
+}
+
+static void free_old_xmit_skbs(struct virtnet_info *vi)
+{
+ struct sk_buff *skb;
+ unsigned int len;
+
+ while ((skb = vi->svq->vq_ops->get_buf(vi->svq, &len)) != NULL) {
+ pr_debug("Sent skb %p\n", skb);
+ __skb_unlink(skb, &vi->send);
+ vi->dev->stats.tx_bytes += len;
+ vi->dev->stats.tx_packets++;
+ kfree_skb(skb);
+ }
+}
+
+static int start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ int num, err;
+ struct scatterlist sg[1+MAX_SKB_FRAGS];
+ struct virtio_net_hdr *hdr;
+ const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest;
+
+ pr_debug("%s: xmit %p %02x:%02x:%02x:%02x:%02x:%02x\n",
+ dev->name, skb,
+ dest[0], dest[1], dest[2], dest[3], dest[4], dest[5]);
+
+ free_old_xmit_skbs(vi);
+
+ /* Encode metadata header at front. */
+ hdr = skb_vnet_hdr(skb);
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ hdr->flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
+ hdr->csum_start = skb->csum_start - skb_headroom(skb);
+ hdr->csum_offset = skb->csum_offset;
+ } else {
+ hdr->flags = 0;
+ hdr->csum_offset = hdr->csum_start = 0;
+ }
+
+ if (skb_is_gso(skb)) {
+ hdr->gso_size = skb_shinfo(skb)->gso_size;
+ if (skb_shinfo(skb)->gso_type & SKB_GSO_TCP_ECN)
+ hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4_ECN;
+ else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV4)
+ hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
+ else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
+ hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
+ hdr->gso_type = VIRTIO_NET_HDR_GSO_UDP;
+ else
+ BUG();
+ } else {
+ hdr->gso_type = VIRTIO_NET_HDR_GSO_NONE;
+ hdr->gso_size = 0;
+ }
+
+ vnet_hdr_to_sg(sg, skb);
+ num = skb_to_sgvec(skb, sg+1, 0, skb->len) + 1;
+ __skb_queue_head(&vi->send, skb);
+ err = vi->svq->vq_ops->add_buf(vi->svq, sg, num, 0, skb);
+ if (err) {
+ pr_debug("%s: virtio not prepared to send\n", dev->name);
+ skb_unlink(skb, &vi->send);
+ netif_stop_queue(dev);
+ return NETDEV_TX_BUSY;
+ }
+ vi->svq->vq_ops->kick(vi->svq);
+
+ return 0;
+}
+
+static int virtnet_open(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+
+ try_fill_recv(vi);
+
+ /* If we didn't even get one input buffer, we're useless. */
+ if (vi->num == 0)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int virtnet_close(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct sk_buff *skb;
+
+ /* networking core has neutered skb_xmit_done/skb_recv_done, so don't
+ * worry about races vs. get(). */
+ vi->rvq->vq_ops->shutdown(vi->rvq);
+ while ((skb = __skb_dequeue(&vi->recv)) != NULL) {
+ kfree_skb(skb);
+ vi->num--;
+ }
+ vi->svq->vq_ops->shutdown(vi->svq);
+ while ((skb = __skb_dequeue(&vi->send)) != NULL)
+ kfree_skb(skb);
+
+ BUG_ON(vi->num != 0);
+ return 0;
+}
+
+static int virtnet_probe(struct virtio_device *vdev)
+{
+ int err;
+ unsigned int len;
+ struct net_device *dev;
+ struct virtnet_info *vi;
+ void *token;
+
+ /* Allocate ourselves a network device with room for our info */
+ dev = alloc_etherdev(sizeof(struct virtnet_info));
+ if (!dev)
+ return -ENOMEM;
+
+ /* Set up network device as normal. */
+ SET_MODULE_OWNER(dev);
+ ether_setup(dev);
+ dev->open = virtnet_open;
+ dev->stop = virtnet_close;
+ dev->poll = virtnet_poll;
+ dev->hard_start_xmit = start_xmit;
+ dev->weight = 16;
+ dev->features = NETIF_F_HIGHDMA;
+ SET_NETDEV_DEV(dev, &vdev->dev);
+
+ /* Do we support "hardware" checksums? */
+ token = vdev->config->find(vdev, VIRTIO_CONFIG_NET_F, &len);
+ if (virtio_use_bit(vdev, token, len, VIRTIO_NET_F_NO_CSUM)) {
+ /* This opens up the world of extra features. */
+ dev->features |= NETIF_F_HW_CSUM|NETIF_F_SG|NETIF_F_FRAGLIST;
+ if (virtio_use_bit(vdev, token, len, VIRTIO_NET_F_TSO4))
+ dev->features |= NETIF_F_TSO;
+ if (virtio_use_bit(vdev, token, len, VIRTIO_NET_F_UFO))
+ dev->features |= NETIF_F_UFO;
+ if (virtio_use_bit(vdev, token, len, VIRTIO_NET_F_TSO4_ECN))
+ dev->features |= NETIF_F_TSO_ECN;
+ if (virtio_use_bit(vdev, token, len, VIRTIO_NET_F_TSO6))
+ dev->features |= NETIF_F_TSO6;
+ }
+
+ /* Configuration may specify what MAC to use. Otherwise random. */
+ token = vdev->config->find(vdev, VIRTIO_CONFIG_NET_MAC_F, &len);
+ if (token) {
+ dev->addr_len = len;
+ vdev->config->get(vdev, token, dev->dev_addr, len);
+ } else
+ random_ether_addr(dev->dev_addr);
+
+ /* Set up our device-specific information */
+ vi = netdev_priv(dev);
+ vi->dev = dev;
+ vi->vdev = vdev;
+
+ /* We expect two virtqueues, receive then send. */
+ vi->rvq = vdev->config->find_vq(vdev, skb_recv_done);
+ if (IS_ERR(vi->rvq)) {
+ err = PTR_ERR(vi->rvq);
+ goto free;
+ }
+
+ vi->svq = vdev->config->find_vq(vdev, skb_xmit_done);
+ if (IS_ERR(vi->svq)) {
+ err = PTR_ERR(vi->svq);
+ goto free_recv;
+ }
+
+ /* Initialize our empty receive and send queues. */
+ skb_queue_head_init(&vi->recv);
+ skb_queue_head_init(&vi->send);
+
+ err = register_netdev(dev);
+ if (err) {
+ pr_debug("virtio_net: registering device failed\n");
+ goto free_send;
+ }
+ pr_debug("virtnet: registered device %s\n", dev->name);
+ vdev->priv = vi;
+ return 0;
+
+free_send:
+ vdev->config->del_vq(vi->svq);
+free_recv:
+ vdev->config->del_vq(vi->rvq);
+free:
+ free_netdev(dev);
+ return err;
+}
+
+static void virtnet_remove(struct virtio_device *vdev)
+{
+ unregister_netdev(vdev->priv);
+ free_netdev(vdev->priv);
+}
+
+static struct virtio_device_id id_table[] = {
+ { VIRTIO_ID_NET, VIRTIO_DEV_ANY_ID },
+ { 0 },
+};
+
+static struct virtio_driver virtio_net = {
+ .driver.name = KBUILD_MODNAME,
+ .driver.owner = THIS_MODULE,
+ .id_table = id_table,
+ .probe = virtnet_probe,
+ .remove = __devexit_p(virtnet_remove),
+};
+
+static int __init init(void)
+{
+ return register_virtio_driver(&virtio_net);
+}
+
+static void __exit fini(void)
+{
+ unregister_virtio_driver(&virtio_net);
+}
+module_init(init);
+module_exit(fini);
+
+MODULE_DEVICE_TABLE(virtio, id_table);
+MODULE_DESCRIPTION("Virtio network driver");
+MODULE_LICENSE("GPL");
===================================================================
--- /dev/null
+++ b/include/linux/virtio_net.h
@@ -0,0 +1,36 @@
+#ifndef _LINUX_VIRTIO_NET_H
+#define _LINUX_VIRTIO_NET_H
+#include <linux/virtio_config.h>
+
+/* The ID for virtio_net */
+#define VIRTIO_ID_NET 1
+
+/* The bitmap of config for virtio net */
+#define VIRTIO_CONFIG_NET_F 0x40
+#define VIRTIO_NET_F_NO_CSUM 0
+#define VIRTIO_NET_F_TSO4 1
+#define VIRTIO_NET_F_UFO 2
+#define VIRTIO_NET_F_TSO4_ECN 3
+#define VIRTIO_NET_F_TSO6 4
+
+/* The config defining mac address. */
+#define VIRTIO_CONFIG_NET_MAC_F 0x41
+
+/* This is the first element of the scatter-gather list. If you don't
+ * specify GSO or CSUM features, you can simply ignore the header. */
+struct virtio_net_hdr
+{
+#define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 // Use csum_start, csum_offset
+ __u8 flags;
+#define VIRTIO_NET_HDR_GSO_NONE 0 // Not a GSO frame
+#define VIRTIO_NET_HDR_GSO_TCPV4 1 // GSO frame, IPv4 TCP (TSO)
+/* FIXME: Do we need this? If they said they can handle ECN, do they care? */
+#define VIRTIO_NET_HDR_GSO_TCPV4_ECN 2 // GSO frame, IPv4 TCP w/ ECN
+#define VIRTIO_NET_HDR_GSO_UDP 3 // GSO frame, IPv4 UDP (UFO)
+#define VIRTIO_NET_HDR_GSO_TCPV6 4 // GSO frame, IPv6 TCP
+ __u8 gso_type;
+ __u16 gso_size;
+ __u16 csum_start;
+ __u16 csum_offset;
+};
+#endif /* _LINUX_VIRTIO_NET_H */
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
^ permalink raw reply
* net-2.6.24 rebased...
From: David Miller @ 2007-09-26 6:33 UTC (permalink / raw)
To: netdev; +Cc: linville, jeff, akpm
Ok the rebase is complete and I integrated all of the
"easy" stuff in my backlog. In the usual spot:
kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
John, one patch didn't go in cleanly after I removed the
Z1211 driver. I put it here for your consideration so it
doesn't get lost:
http://vger.kernel.org/~davem/0433-Z1211-Fix-TX-status-reports.patch
What probably needs to happen is some other changes that
were in z1211 need to go into the non-mac80211 driver and
then this patch applies correctly.
I tried the simple thing to rename the directory in the patch
and that didn't work, obviously :-)
Jeff, if you have any pending driver bits please toss them my
way as most of my backlog is clear now.
Andrew, I applied a good chunk of the driver build fixes you had
accumulated. I think I missed one or two, so please check that out
and send my way the ones that I missed.
Thanks!
^ permalink raw reply
* Re: [SCTP PULL Request]: Bug fixes for 2.6.23
From: David Miller @ 2007-09-26 5:53 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, lksctp-developers
In-Reply-To: <46F8252D.3090803@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Mon, 24 Sep 2007 16:59:25 -0400
> Can you please pull the following changes since commit a41d3015c11a4e864b95cb57f579f2d8f40cd41b:
I had to apply this by hand because:
> David S. Miller (1):
> Revert "PCI: disable MSI by default on systems with Serverworks HT1000 chips"
You did this work on a very old tree of mine that I redid
at one point. This MSI changeset I yanked out of my net-2.6
tree during a rebase, so if I pull I get the thing back
which I definitely don't want :-)
Just to let you know what's happening and why I couldn't
pull directly from your tree into mine.
^ permalink raw reply
* Re: [RFC PATCH 3/3] [TCP] MIB: Count FRTO's successfully detected spurious RTOs
From: David Miller @ 2007-09-26 5:47 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <11906246481619-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 24 Sep 2007 12:04:08 +0300
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
This also looks fine, applied, thanks!
^ permalink raw reply
* Re: [RFC PATCH 2/3] [TCP]: Reordered ACK's (old) SACKs not included to discarded MIB
From: David Miller @ 2007-09-26 5:47 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <11906246484144-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 24 Sep 2007 12:04:07 +0300
> In case of ACK reordering, the SACK block might be valid in it's
> time but is already obsoleted since we've received another kind
> of confirmation about arrival of the segments through snd_una
> advancement of an earlier packet.
>
> I didn't bother to build distinguishing of valid and invalid
> SACK blocks but simply made reordered SACK blocks that are too
> old always not counted regardless of their "real" validity which
> could be determined by using the ack field of the reordered
> packet (won't be significant IMHO).
>
> DSACKs can very well be considered useful even in this situation,
> so won't do any of this for them.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
This looks fine to me, applied.
If the skipped case is interesting we can add another MIB
stat for it :-)
^ permalink raw reply
* Re: [PATCH 1/3] [TCP]: Re-place highest_sack check to a more robust position
From: David Miller @ 2007-09-26 5:44 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <11906246483657-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 24 Sep 2007 12:04:06 +0300
> I previously added checking to position that is rather poor as
> state has already been adjusted quite a bit. Re-placing it above
> all state changes should be more robust though the return should
> never ever get executed regardless of its place :-).
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Applied to net-2.6.24, thanks Ilpo.
^ permalink raw reply
* Re: Please pull 'upstream-davem' branch of wireless-2.6 (for 2.6.24)
From: David Miller @ 2007-09-26 5:38 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070922195457.GA22629-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Sat, 22 Sep 2007 15:54:57 -0400
> The individual patches are available here:
>
> http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem/
I sucked these into my net-2.6.24 tree, thanks John.
It may look slightly different because I applied the iwlwifi
CFLAGS Makefile patch directly from Intel and I did the
iwlwifi directory source move on my own.
Thanks!
^ permalink raw reply
* Re: [RFC] Zero-length write() does not generate a datagram on connected socket
From: Stephen Hemminger @ 2007-09-26 5:36 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <E1IaNQ7-0004DX-00@gondolin.me.apana.org.au>
On Wed, 26 Sep 2007 11:18:39 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> > The bug http://bugzilla.kernel.org/show_bug.cgi?id=5731
> > describes an issue where write() can't be used to generate a zero-length
> > datagram (but send, and sendto do work).
> >
> > I think the following is needed:
> >
> > --- a/net/socket.c 2007-08-20 09:54:28.000000000 -0700
> > +++ b/net/socket.c 2007-09-24 15:31:25.000000000 -0700
> > @@ -777,8 +777,11 @@ static ssize_t sock_aio_write(struct kio
> > if (pos != 0)
> > return -ESPIPE;
> >
> > - if (iocb->ki_left == 0) /* Match SYS5 behaviour */
> > - return 0;
> > + if (unlikely(iocb->ki_left == 0)) {
> > + struct socket *sock = iocb->ki_filp->private_data;
> > + if (sock->type == SOCK_STREAM)
> > + return 0;
> > + }
>
> I'm not sure whether all STREAM protocols treat zero-length
> sends as no-ops. What about SCTP?
>
> Put it another way, do we really need to keep the short-circuit
> for SOCK_STREAM?
>
> Cheers,
Stream is defined as sequence of bytes. So short circuit makes sense
If the application wants message boundaries it needs to use SOCK_SEQPACKET.
I was paranoid about possible breakage in TCP or SCTP. But since
send(s, buf, 0, 0) already filters through, I guess it doesn't matter.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
From: Jeff Garzik @ 2007-09-26 5:18 UTC (permalink / raw)
To: David Miller; +Cc: joe, netdev, akpm
In-Reply-To: <20070925.221115.26296263.davem@davemloft.net>
David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Tue, 25 Sep 2007 21:36:38 -0700
>
>> On Tue, 2007-09-25 at 19:29 -0700, David Miller wrote:
>>> I'm going to hold on this for now, there is no universal
>>> agreement that this is something we want to do and I'd
>>> like to take care of getting the more certain stuff into
>>> net-2.6.24 before "iffy" bits like this one.
>> Here's an argument for inclusion:
>>
>> defconfig without patches:
>
> Sure, but this ignores certain things that text/data/bss
> size don't show you.
size(1) output also ignores the merge noise this creates, and IMO we've
got a lot of that already...
Jeff
^ permalink raw reply
* Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
From: David Miller @ 2007-09-26 5:11 UTC (permalink / raw)
To: joe; +Cc: netdev, jgarzik, akpm
In-Reply-To: <1190781398.17052.18.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Tue, 25 Sep 2007 21:36:38 -0700
> On Tue, 2007-09-25 at 19:29 -0700, David Miller wrote:
> > I'm going to hold on this for now, there is no universal
> > agreement that this is something we want to do and I'd
> > like to take care of getting the more certain stuff into
> > net-2.6.24 before "iffy" bits like this one.
>
> Here's an argument for inclusion:
>
> defconfig without patches:
Sure, but this ignores certain things that text/data/bss
size don't show you.
For one thing, stack frames might now be larger in the
functions where the new variables get added, even if they
aren't used to print out the debugging message. And that
could have negative performance implications.
Nothing is every black and white, everything is gray :-)
^ permalink raw reply
* Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
From: Joe Perches @ 2007-09-26 4:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jgarzik, akpm
In-Reply-To: <20070925.192917.21908774.davem@davemloft.net>
On Tue, 2007-09-25 at 19:29 -0700, David Miller wrote:
> I'm going to hold on this for now, there is no universal
> agreement that this is something we want to do and I'd
> like to take care of getting the more certain stuff into
> net-2.6.24 before "iffy" bits like this one.
Here's an argument for inclusion:
defconfig without patches:
$ size vmlinux
text data bss dec hex filename
4738370 518986 622592 5879948 59b88c vmlinux
defconfig with patches:
$ size vmlinux
text data bss dec hex filename
4735238 518986 622592 5876816 59ac50 vmlinux
cheers, Joe
^ permalink raw reply
* Re: [RFC] Zero-length write() does not generate a datagram on connected socket
From: Herbert Xu @ 2007-09-26 3:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20070924153435.14249225@freepuppy.rosehill>
Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> The bug http://bugzilla.kernel.org/show_bug.cgi?id=5731
> describes an issue where write() can't be used to generate a zero-length
> datagram (but send, and sendto do work).
>
> I think the following is needed:
>
> --- a/net/socket.c 2007-08-20 09:54:28.000000000 -0700
> +++ b/net/socket.c 2007-09-24 15:31:25.000000000 -0700
> @@ -777,8 +777,11 @@ static ssize_t sock_aio_write(struct kio
> if (pos != 0)
> return -ESPIPE;
>
> - if (iocb->ki_left == 0) /* Match SYS5 behaviour */
> - return 0;
> + if (unlikely(iocb->ki_left == 0)) {
> + struct socket *sock = iocb->ki_filp->private_data;
> + if (sock->type == SOCK_STREAM)
> + return 0;
> + }
I'm not sure whether all STREAM protocols treat zero-length
sends as no-ops. What about SCTP?
Put it another way, do we really need to keep the short-circuit
for SOCK_STREAM?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Please pull 'fixes-davem' branch of wireless-2.6 (for 2.6.23)
From: David Miller @ 2007-09-26 2:44 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070922154142.GA4738-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Sat, 22 Sep 2007 11:41:42 -0400
> These are a few more minor fixes that I would like to have in 2.6.23 if
> at all possible.
I've pulled these into my net-2.6 tree and will push to
Linus, thanks!
^ permalink raw reply
* Re: [PATCH] note that NETIF_F_LLTX is deprecated
From: David Miller @ 2007-09-26 2:42 UTC (permalink / raw)
To: herbert; +Cc: borntraeger, jeff, netdev
In-Reply-To: <20070922005709.GA17022@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 22 Sep 2007 08:57:10 +0800
> On Fri, Sep 21, 2007 at 04:59:54PM +0200, Christian Borntraeger wrote:
> >
> > I suggest to document that LLTX is deprecated.
> >
> > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>
> This looks good to me.
To me too, applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: Please pull 'iwlwifi' branch of wireless-2.6
From: David Miller @ 2007-09-26 2:31 UTC (permalink / raw)
To: linville; +Cc: yi.zhu, hch, jeff, netdev, linux-wireless
In-Reply-To: <20070921013403.GA3170@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 20 Sep 2007 21:34:03 -0400
> On Fri, Sep 21, 2007 at 09:20:30AM +0800, Zhu Yi wrote:
> > On Wed, 2007-09-19 at 11:13 +0100, Christoph Hellwig wrote:
> > > it really needs to be moved into a directory of it's own.
> >
> > It used to be... John?
>
> Fine by me -- I guess I misinterpreted the some other statements to
> make me think we wanted as flat a directory structure as possible.
I've taken care of this during the net-2.6.24 rebase I'm working
on today.
^ permalink raw reply
* Re: [patch 1/1] revert "8139too: clean up I/O remapping"
From: David Miller @ 2007-09-26 2:30 UTC (permalink / raw)
To: jeff; +Cc: akpm, michal.k.k.piotrowski, netdev
In-Reply-To: <46F2DF03.1060501@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Thu, 20 Sep 2007 16:58:43 -0400
> akpm@linux-foundation.org wrote:
> > From: Andrew Morton <akpm@linux-foundation.org>
> >
> > Revert git-netdev-all's 9ee6b32a47b9abc565466a9c3b127a5246b452e5. Michal was
> > getting oopses.
> >
> > Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> > Cc: Jeff Garzik <jeff@garzik.org>
> > Cc: David S. Miller" <davem@davemloft.net>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> >
> > drivers/net/8139too.c | 50 +++++++++++++++++++++++-----------------
> > 1 file changed, 29 insertions(+), 21 deletions(-)
>
> ACK -- DaveM, please remove or revert this patch.
>
I've reverted this patch during the net-2.6.24 rebase I'm
working on today.
^ permalink raw reply
* Re: [PATCH - net-2.6.24 0/2] Introduce and use print_ip and print_ipv6
From: David Miller @ 2007-09-26 2:29 UTC (permalink / raw)
To: joe; +Cc: netdev, jgarzik, akpm
In-Reply-To: <1190271211.26101.91.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Wed, 19 Sep 2007 23:53:31 -0700
> In the same vein as print_mac, the implementations
> introduce declaration macros:
I'm going to hold on this for now, there is no universal
agreement that this is something we want to do and I'd
like to take care of getting the more certain stuff into
net-2.6.24 before "iffy" bits like this one.
Thanks.
^ permalink raw reply
* Re: [RFC][NET_SCHED] explict hold dev tx lock
From: David Miller @ 2007-09-26 2:28 UTC (permalink / raw)
To: hadi; +Cc: herbert, netdev, kaber, dada1, johnpol
In-Reply-To: <1190256183.4818.28.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Wed, 19 Sep 2007 22:43:03 -0400
> [NET_SCHED] explict hold dev tx lock
>
> For N cpus, with full throttle traffic on all N CPUs, funneling traffic
> to the same ethernet device, the devices queue lock is contended by all
> N CPUs constantly. The TX lock is only contended by a max of 2 CPUS.
> In the current mode of operation, after all the work of entering the
> dequeue region, we may endup aborting the path if we are unable to get
> the tx lock and go back to contend for the queue lock. As N goes up,
> this gets worse.
>
> The changes in this patch result in a small increase in performance
> with a 4CPU (2xdual-core) with no irq binding. Both e1000 and tg3
> showed similar behavior;
>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
I've applied this to net-2.6.24, although I want to study more deeply
the implications of this change myself at some point :)
^ permalink raw reply
* Re: [PATCH 0/3] move hardware header functions out of netdevice
From: David Miller @ 2007-09-26 2:24 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20070824204310.388073598@linux-foundation.org>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Fri, 24 Aug 2007 13:43:10 -0700
> The follow patches series starts the process of moving function
> pointers out of network device structure. This saves space and
> separates code from data.
>
> The first step is moving the functions dealing with hardware
> headers.
>
> Patches are against current net-2.6.24 tree. Basic functional
> testing on ethernet part, not on all the other protocols affected.
Stephen, can you respin these against net-2.6.24 and resubmit?
Thanks!
^ permalink raw reply
* Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
From: David Miller @ 2007-09-26 2:24 UTC (permalink / raw)
To: ebiederm
Cc: pjwaskiewicz, dlezcano, shemminger, netdev, containers,
benjamin.thery
In-Reply-To: <m1r6kwpu9t.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Mon, 17 Sep 2007 20:44:14 -0600
> David Miller <davem@davemloft.net> writes:
>
> > From: "Peter Waskiewicz" <pjwaskiewicz@gmail.com>
> > Date: Mon, 17 Sep 2007 12:12:24 -0700
> >
> >> This would be a good opportunity to remove the single-allocated queue struct
> >> in netdevice (at the bottom) that we had to put in to accomodate the static
> >> loopback. Now we can set it back to a zero element list, and have
> >> alloc_netdev_mq() just allocate the number of queues requested, not
> >> num_queues - 1.
> >>
> >> I'll put a patch together based on this patchset.
> >
> > Thanks Peter.
> >
> > I'll also let this sit so that Eric can provide any feedback
> > he wants and also figure out how he will use this for the
> > namespace stuff.
>
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> Not that it doesn't already have my signed off by.
I've put these patches into the just-rebased net-2.6.24 tree.
I made a minor modification to the second patch, the
out_free_netdev: code in loopback_init() ended like this:
out_free_netdev:
free_netdev(dev);
goto out;
return err;
};
I got rid of the spurious return statement and the trailing
semi-colon after the function closing brace.
Thanks.
^ 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