* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Eric Dumazet @ 2009-11-20 5:24 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <412e6f7f0911192111jbc8b237sc619a54510219336@mail.gmail.com>
Changli Gao a écrit :
> You call xps_flush() in net_rx_aciton(). It means that if no new
> packet arrives, xps_flush() won't be called forever, and the memory
> used by skbs will be hold forever. Did I misunderstand? Your algorithm
> only works with packet forwarding but sending packets from local
> sockets.
>
Please re-read my patch, you misunderstood it, or I dont get you.
If xps_consume_skb(skb) is ever called (from one to XXX times),
then we xps_flush() them, from net_rx_action()
net_rx_action()
{
while (has_work) {
perform_napi_things(); // calls xps_consume_skb()
}
xps_flush(); // post things to remote cpus, and dont leak memory
}
This net_rx_action() is same for forwarding and localy generated packets.
^ permalink raw reply
* Re: [PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
From: Eric Dumazet @ 2009-11-20 5:28 UTC (permalink / raw)
To: Sean Hefty
Cc: 'Roland Dreier', David S. Miller, Linux Netdev List,
Roland Dreier, Hal Rosenstock, linux-rdma
In-Reply-To: <8C10E584257A46DB9A0AD193520CF4A7-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
Sean Hefty a écrit :
>> Would it be possible for you to take Eric's patch as the first in your
>> set (keeping his From: of course) and base your fixes on top of that?
>
> Will do.
>
Any news of this patch ?
We need it for 2.6.32 and also to prepare 2.6.33 with upcoming patches.
Thanks
[PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
for_each_netdev() should be used with RTNL or dev_base_lock held,
or risk a crash.
Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/infiniband/core/addr.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index bd07803..5ca0b2c 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -131,6 +131,7 @@ int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr)
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
case AF_INET6:
+ read_lock(&dev_base_lock);
for_each_netdev(&init_net, dev) {
if (ipv6_chk_addr(&init_net,
&((struct sockaddr_in6 *) addr)->sin6_addr,
@@ -139,6 +140,7 @@ int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr)
break;
}
}
+ read_unlock(&dev_base_lock);
break;
#endif
}
@@ -391,15 +393,17 @@ static int addr_resolve_local(struct sockaddr *src_in,
{
struct in6_addr *a;
+ read_lock(&dev_base_lock);
for_each_netdev(&init_net, dev)
if (ipv6_chk_addr(&init_net,
&((struct sockaddr_in6 *) dst_in)->sin6_addr,
dev, 1))
break;
- if (!dev)
+ if (!dev) {
+ read_unlock(&dev_base_lock);
return -EADDRNOTAVAIL;
-
+ }
a = &((struct sockaddr_in6 *) src_in)->sin6_addr;
if (ipv6_addr_any(a)) {
@@ -416,6 +420,7 @@ static int addr_resolve_local(struct sockaddr *src_in,
if (!ret)
memcpy(addr->dst_dev_addr, dev->dev_addr, MAX_ADDR_LEN);
}
+ read_unlock(&dev_base_lock);
break;
}
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Changli Gao @ 2009-11-20 5:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <4B0627FA.3060103@gmail.com>
On Fri, Nov 20, 2009 at 1:24 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Changli Gao a écrit :
>
> Please re-read my patch, you misunderstood it, or I dont get you.
I think I didn't misunderstand it. If local socket only sends packets,
which don't need replies from receiver, so new NIC RX IRQ, and NET_RX
softirq won't be triggered. Who will call xps_flush() to free the
memory used by locally generated packets?
>
> If xps_consume_skb(skb) is ever called (from one to XXX times),
> then we xps_flush() them, from net_rx_action()
>
> net_rx_action()
> {
> while (has_work) {
> perform_napi_things(); // calls xps_consume_skb()
> }
> xps_flush(); // post things to remote cpus, and dont leak memory
> }
>
> This net_rx_action() is same for forwarding and localy generated packets.
>
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
From: Stephen Hemminger @ 2009-11-20 5:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Sean Hefty, 'Roland Dreier', David S. Miller,
Linux Netdev List, Roland Dreier, Hal Rosenstock, linux-rdma
In-Reply-To: <4B0628E0.6000404-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 20 Nov 2009 06:28:00 +0100
Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> + read_lock(&dev_base_lock);
> for_each_netdev(&init_net, dev) {
> if (ipv6_chk_addr(&init_net,
> &((struct sockaddr_in6 *) addr)->sin6_addr,
> @@ -139,6 +140,7 @@ int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr)
> break;
> }
> }
> + read_unlock(&dev_base_lock);
what about for_each_netdev_rcu() here instead...
--
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Eric Dumazet @ 2009-11-20 5:42 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <412e6f7f0911192134m24beca36m1887513513f130b8@mail.gmail.com>
Changli Gao a écrit :
> On Fri, Nov 20, 2009 at 1:24 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Changli Gao a écrit :
>>
>> Please re-read my patch, you misunderstood it, or I dont get you.
>
> I think I didn't misunderstand it. If local socket only sends packets,
> which don't need replies from receiver, so new NIC RX IRQ, and NET_RX
> softirq won't be triggered. Who will call xps_flush() to free the
> memory used by locally generated packets?
>
Changli, when we transmit a skb on NIC, NIC is supposed to have a TX completion
call back, to free this skb.
These completion calls are running from net_rx_action(), if driver is NAPI enabled.
Only NAPI enabled drivers are allowed to use XPS infrastructure.
I sent 100.000.000 packets in my pktgen+tg3 tests, without receiving a single packet
in return, I can tell you all packets were correctly freed :)
^ permalink raw reply
* Re: [PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
From: Eric Dumazet @ 2009-11-20 5:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Sean Hefty, 'Roland Dreier', David S. Miller,
Linux Netdev List, Roland Dreier, Hal Rosenstock, linux-rdma
In-Reply-To: <20091119214047.1a966c79@nehalam>
Stephen Hemminger a écrit :
> On Fri, 20 Nov 2009 06:28:00 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> + read_lock(&dev_base_lock);
>> for_each_netdev(&init_net, dev) {
>> if (ipv6_chk_addr(&init_net,
>> &((struct sockaddr_in6 *) addr)->sin6_addr,
>> @@ -139,6 +140,7 @@ int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr)
>> break;
>> }
>> }
>> + read_unlock(&dev_base_lock);
>
> what about for_each_netdev_rcu() here instead...
>
Yes, in 2.6.33 :)
For 2.6.32, we need this patch
Thanks
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Changli Gao @ 2009-11-20 5:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <4B062C51.8090100@gmail.com>
On Fri, Nov 20, 2009 at 1:42 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Changli Gao a écrit :
>> On Fri, Nov 20, 2009 at 1:24 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> Changli Gao a écrit :
>>>
>>> Please re-read my patch, you misunderstood it, or I dont get you.
>>
>> I think I didn't misunderstand it. If local socket only sends packets,
>> which don't need replies from receiver, so new NIC RX IRQ, and NET_RX
>> softirq won't be triggered. Who will call xps_flush() to free the
>> memory used by locally generated packets?
>>
>
> Changli, when we transmit a skb on NIC, NIC is supposed to have a TX completion
> call back, to free this skb.
>
> These completion calls are running from net_rx_action(), if driver is NAPI enabled.
>
> Only NAPI enabled drivers are allowed to use XPS infrastructure.
>
> I sent 100.000.000 packets in my pktgen+tg3 tests, without receiving a single packet
> in return, I can tell you all packets were correctly freed :)
>
>
Oh, I am so sorry. It seems I missed sth. I need to review the new
NAPI. Thanks for your patience and help.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH 0/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
From: Shirley Ma @ 2009-11-20 6:09 UTC (permalink / raw)
To: Michael S. Tsirkin, Avi Kivity, Rusty Russell, netdev, kvm,
linux-kernel
Guest virtio_net receives packets from its pre-allocated vring
buffers, then it delivers these packets to upper layer protocols
as skb buffs. So it's not necessary to pre-allocate skb for each
mergable buffer, then frees it when it's useless.
This patch has deferred skb allocation when receiving packets for
both big packets and mergeable buffers. It reduces skb pre-allocations
and skb_frees.
Based on Mickael & Avi's suggestion. A destroy function has been created
to push virtio free buffs to vring for unused pages, and used page private
to maintain page list.
I didn't touch small packet skb allocation to avoid extra copies for small
packets.
This patch has tested and measured against 2.6.32-rc5 git. It is built again
2.6.32-rc7 kernel. Tests have been done for small packets, big packets and
mergeable buffers.
The single netperf TCP_STREAM performance improved for host to guest.
It also reduces UDP packets drop rate.
The netperf laptop results were:
mtu=1500
netperf -H xxx -l 120
w/o patch w/i patch (two runs)
guest to host: 3336.84Mb/s 3730.14Mb/s ~ 3582.88Mb/s
host to guest: 3165.10Mb/s 3370.39Mb/s ~ 3407.96Mb/s
^ permalink raw reply
* [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
From: Shirley Ma @ 2009-11-20 6:15 UTC (permalink / raw)
To: Michael S. Tsirkin, Avi Kivity, Rusty Russell, netdev, kvm,
linux-kernel
This patch is generated against 2.6 git tree. I didn't break up this
patch since it has one functionality. Please review it.
Thanks
Shirley
Signed-off-by: Shirley Ma <xma@us.ibm.com>
------
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b9e002f..6fb788b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -80,33 +80,48 @@ static inline struct skb_vnet_hdr *skb_vnet_hdr(struct sk_buff *skb)
return (struct skb_vnet_hdr *)skb->cb;
}
-static void give_a_page(struct virtnet_info *vi, struct page *page)
+static void give_pages(struct virtnet_info *vi, struct page *page)
{
- page->private = (unsigned long)vi->pages;
+ struct page *npage = (struct page *)page->private;
+
+ if (!npage)
+ page->private = (unsigned long)vi->pages;
+ else {
+ /* give a page list */
+ while (npage) {
+ if (npage->private == (unsigned long)0) {
+ npage->private = (unsigned long)vi->pages;
+ break;
+ }
+ npage = (struct page *)npage->private;
+ }
+ }
vi->pages = page;
}
-static void trim_pages(struct virtnet_info *vi, struct sk_buff *skb)
-{
- unsigned int i;
-
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
- give_a_page(vi, skb_shinfo(skb)->frags[i].page);
- skb_shinfo(skb)->nr_frags = 0;
- skb->data_len = 0;
-}
-
static struct page *get_a_page(struct virtnet_info *vi, gfp_t gfp_mask)
{
struct page *p = vi->pages;
- if (p)
+ if (p) {
vi->pages = (struct page *)p->private;
- else
+ /* use private to chain big packets */
+ p->private = (unsigned long)0;
+ } else
p = alloc_page(gfp_mask);
return p;
}
+void virtio_free_pages(void *buf)
+{
+ struct page *page = (struct page *)buf;
+
+ while (page) {
+ __free_pages(page, 0);
+ page = (struct page *)page->private;
+ }
+}
+
static void skb_xmit_done(struct virtqueue *svq)
{
struct virtnet_info *vi = svq->vdev->priv;
@@ -118,12 +133,36 @@ static void skb_xmit_done(struct virtqueue *svq)
netif_wake_queue(vi->dev);
}
-static void receive_skb(struct net_device *dev, struct sk_buff *skb,
+static int set_skb_frags(struct sk_buff *skb, struct page *page,
+ int offset, int len)
+{
+ int i = skb_shinfo(skb)->nr_frags;
+ skb_frag_t *f;
+
+ i = skb_shinfo(skb)->nr_frags;
+ f = &skb_shinfo(skb)->frags[i];
+ f->page = page;
+ f->page_offset = offset;
+
+ if (len > (PAGE_SIZE - f->page_offset))
+ f->size = PAGE_SIZE - f->page_offset;
+ else
+ f->size = len;
+
+ skb_shinfo(skb)->nr_frags++;
+ skb->data_len += f->size;
+ skb->len += f->size;
+
+ len -= f->size;
+ return len;
+}
+
+static void receive_skb(struct net_device *dev, void *buf,
unsigned len)
{
struct virtnet_info *vi = netdev_priv(dev);
- struct skb_vnet_hdr *hdr = skb_vnet_hdr(skb);
- int err;
+ struct skb_vnet_hdr *hdr;
+ struct sk_buff *skb;
int i;
if (unlikely(len < sizeof(struct virtio_net_hdr) + ETH_HLEN)) {
@@ -132,39 +171,71 @@ static void receive_skb(struct net_device *dev, struct sk_buff *skb,
goto drop;
}
- if (vi->mergeable_rx_bufs) {
- unsigned int copy;
- char *p = page_address(skb_shinfo(skb)->frags[0].page);
+ if (!vi->mergeable_rx_bufs && !vi->big_packets) {
+ skb = (struct sk_buff *)buf;
+
+ __skb_unlink(skb, &vi->recv);
+
+ hdr = skb_vnet_hdr(skb);
+ len -= sizeof(hdr->hdr);
+ skb_trim(skb, len);
+ } else {
+ struct page *page = (struct page *)buf;
+ int copy, hdr_len, num_buf, offset;
+ char *p;
+
+ p = page_address(page);
- if (len > PAGE_SIZE)
- len = PAGE_SIZE;
- len -= sizeof(struct virtio_net_hdr_mrg_rxbuf);
+ skb = netdev_alloc_skb(vi->dev, GOOD_COPY_LEN + NET_IP_ALIGN);
+ if (unlikely(!skb)) {
+ dev->stats.rx_dropped++;
+ return;
+ }
+ skb_reserve(skb, NET_IP_ALIGN);
+ hdr = skb_vnet_hdr(skb);
- memcpy(&hdr->mhdr, p, sizeof(hdr->mhdr));
- p += sizeof(hdr->mhdr);
+ if (vi->mergeable_rx_bufs) {
+ hdr_len = sizeof(hdr->mhdr);
+ memcpy(&hdr->mhdr, p, hdr_len);
+ num_buf = hdr->mhdr.num_buffers;
+ offset = hdr_len;
+ if (len > PAGE_SIZE)
+ len = PAGE_SIZE;
+ } else {
+ /* big packtes 6 bytes alignment between virtio_net
+ * header and data */
+ hdr_len = sizeof(hdr->hdr);
+ memcpy(&hdr->hdr, p, hdr_len);
+ offset = hdr_len + 6;
+ }
+
+ p += offset;
+ len -= hdr_len;
copy = len;
if (copy > skb_tailroom(skb))
copy = skb_tailroom(skb);
-
memcpy(skb_put(skb, copy), p, copy);
len -= copy;
- if (!len) {
- give_a_page(vi, skb_shinfo(skb)->frags[0].page);
- skb_shinfo(skb)->nr_frags--;
- } else {
- skb_shinfo(skb)->frags[0].page_offset +=
- sizeof(hdr->mhdr) + copy;
- skb_shinfo(skb)->frags[0].size = len;
- skb->data_len += len;
- skb->len += len;
+ if (!len)
+ give_pages(vi, page);
+ else {
+ len = set_skb_frags(skb, page, copy + offset, len);
+ /* process big packets */
+ while (len > 0) {
+ page = (struct page *)page->private;
+ if (!page)
+ break;
+ len = set_skb_frags(skb, page, 0, len);
+ }
+ if (page && page->private)
+ give_pages(vi, (struct page *)page->private);
}
- while (--hdr->mhdr.num_buffers) {
- struct sk_buff *nskb;
-
+ /* process mergeable buffers */
+ while (vi->mergeable_rx_bufs && --num_buf) {
i = skb_shinfo(skb)->nr_frags;
if (i >= MAX_SKB_FRAGS) {
pr_debug("%s: packet too long %d\n", dev->name,
@@ -173,41 +244,20 @@ static void receive_skb(struct net_device *dev, struct sk_buff *skb,
goto drop;
}
- nskb = vi->rvq->vq_ops->get_buf(vi->rvq, &len);
- if (!nskb) {
+ page = vi->rvq->vq_ops->get_buf(vi->rvq, &len);
+ if (!page) {
pr_debug("%s: rx error: %d buffers missing\n",
dev->name, hdr->mhdr.num_buffers);
dev->stats.rx_length_errors++;
goto drop;
}
- __skb_unlink(nskb, &vi->recv);
- vi->num--;
-
- skb_shinfo(skb)->frags[i] = skb_shinfo(nskb)->frags[0];
- skb_shinfo(nskb)->nr_frags = 0;
- kfree_skb(nskb);
-
if (len > PAGE_SIZE)
len = PAGE_SIZE;
- skb_shinfo(skb)->frags[i].size = len;
- skb_shinfo(skb)->nr_frags++;
- skb->data_len += len;
- skb->len += len;
- }
- } else {
- len -= sizeof(hdr->hdr);
-
- if (len <= MAX_PACKET_LEN)
- trim_pages(vi, skb);
+ set_skb_frags(skb, page, 0, len);
- err = pskb_trim(skb, len);
- if (err) {
- pr_debug("%s: pskb_trim failed %i %d\n", dev->name,
- len, err);
- dev->stats.rx_dropped++;
- goto drop;
+ vi->num--;
}
}
@@ -271,107 +321,105 @@ drop:
dev_kfree_skb(skb);
}
-static bool try_fill_recv_maxbufs(struct virtnet_info *vi, gfp_t gfp)
+/* Returns false if we couldn't fill entirely (OOM). */
+static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
{
- struct sk_buff *skb;
struct scatterlist sg[2+MAX_SKB_FRAGS];
- int num, err, i;
+ int err = 0;
bool oom = false;
sg_init_table(sg, 2+MAX_SKB_FRAGS);
do {
- struct skb_vnet_hdr *hdr;
-
- skb = netdev_alloc_skb(vi->dev, MAX_PACKET_LEN + NET_IP_ALIGN);
- if (unlikely(!skb)) {
- oom = true;
- break;
- }
-
- skb_reserve(skb, NET_IP_ALIGN);
- skb_put(skb, MAX_PACKET_LEN);
-
- hdr = skb_vnet_hdr(skb);
- sg_set_buf(sg, &hdr->hdr, sizeof(hdr->hdr));
-
- if (vi->big_packets) {
- for (i = 0; i < MAX_SKB_FRAGS; i++) {
- skb_frag_t *f = &skb_shinfo(skb)->frags[i];
- f->page = get_a_page(vi, gfp);
- if (!f->page)
- break;
-
- f->page_offset = 0;
- f->size = PAGE_SIZE;
-
- skb->data_len += PAGE_SIZE;
- skb->len += PAGE_SIZE;
-
- skb_shinfo(skb)->nr_frags++;
+ /* allocate skb for MAX_PACKET_LEN len */
+ if (!vi->big_packets && !vi->mergeable_rx_bufs) {
+ struct skb_vnet_hdr *hdr;
+ struct sk_buff *skb;
+
+ skb = netdev_alloc_skb(vi->dev,
+ MAX_PACKET_LEN + NET_IP_ALIGN);
+ if (unlikely(!skb)) {
+ oom = true;
+ break;
}
- }
-
- 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 < 0) {
- skb_unlink(skb, &vi->recv);
- trim_pages(vi, skb);
- kfree_skb(skb);
- break;
- }
- vi->num++;
- } while (err >= num);
- if (unlikely(vi->num > vi->max))
- vi->max = vi->num;
- vi->rvq->vq_ops->kick(vi->rvq);
- return !oom;
-}
-
-/* Returns false if we couldn't fill entirely (OOM). */
-static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
-{
- struct sk_buff *skb;
- struct scatterlist sg[1];
- int err;
- bool oom = false;
- if (!vi->mergeable_rx_bufs)
- return try_fill_recv_maxbufs(vi, gfp);
+ skb_reserve(skb, NET_IP_ALIGN);
+ skb_put(skb, MAX_PACKET_LEN);
- do {
- skb_frag_t *f;
+ hdr = skb_vnet_hdr(skb);
+ sg_set_buf(sg, &hdr->hdr, sizeof(hdr->hdr));
- skb = netdev_alloc_skb(vi->dev, GOOD_COPY_LEN + NET_IP_ALIGN);
- if (unlikely(!skb)) {
- oom = true;
- break;
- }
-
- skb_reserve(skb, NET_IP_ALIGN);
-
- f = &skb_shinfo(skb)->frags[0];
- f->page = get_a_page(vi, gfp);
- if (!f->page) {
- oom = true;
- kfree_skb(skb);
- break;
- }
+ skb_to_sgvec(skb, sg+1, 0, skb->len);
+ skb_queue_head(&vi->recv, skb);
- f->page_offset = 0;
- f->size = PAGE_SIZE;
-
- skb_shinfo(skb)->nr_frags++;
+ err = vi->rvq->vq_ops->add_buf(vi->rvq, sg, 0, 2, skb);
+ if (err < 0) {
+ skb_unlink(skb, &vi->recv);
+ kfree_skb(skb);
+ break;
+ }
- sg_init_one(sg, page_address(f->page), PAGE_SIZE);
- skb_queue_head(&vi->recv, skb);
+ } else {
+ struct page *first_page = NULL;
+ struct page *page;
+ int i = MAX_SKB_FRAGS + 2;
+ char *p;
+
+ /*
+ * chain pages for big packets, allocate skb
+ * late for both big packets and mergeable
+ * buffers
+ */
+more: page = get_a_page(vi, gfp);
+ if (!page) {
+ if (first_page)
+ give_pages(vi, first_page);
+ oom = true;
+ break;
+ }
- err = vi->rvq->vq_ops->add_buf(vi->rvq, sg, 0, 1, skb);
- if (err < 0) {
- skb_unlink(skb, &vi->recv);
- kfree_skb(skb);
- break;
+ p = page_address(page);
+ if (vi->mergeable_rx_bufs) {
+ sg_init_one(sg, p, PAGE_SIZE);
+ err = vi->rvq->vq_ops->add_buf(vi->rvq, sg, 0,
+ 1, page);
+ if (err < 0) {
+ give_pages(vi, page);
+ break;
+ }
+ } else {
+ int hdr_len = sizeof(struct virtio_net_hdr);
+
+ /*
+ * allocate MAX_SKB_FRAGS + 1 pages for
+ * big packets
+ */
+ page->private = (unsigned long)first_page;
+ first_page = page;
+ if (--i == 1) {
+ int offset = hdr_len + 6;
+
+ /*
+ * share one page between virtio_net
+ * header and data, and reserve 6 bytes
+ * for alignment
+ */
+ sg_set_buf(sg, p, hdr_len);
+ sg_set_buf(sg+1, p + offset,
+ PAGE_SIZE - offset);
+ err = vi->rvq->vq_ops->add_buf(vi->rvq,
+ sg, 0,
+ MAX_SKB_FRAGS + 2,
+ first_page);
+ if (err < 0) {
+ give_pages(vi, first_page);
+ break;
+ }
+
+ } else {
+ sg_set_buf(&sg[i], p, PAGE_SIZE);
+ goto more;
+ }
+ }
}
vi->num++;
} while (err > 0);
@@ -411,14 +459,13 @@ static void refill_work(struct work_struct *work)
static int virtnet_poll(struct napi_struct *napi, int budget)
{
struct virtnet_info *vi = container_of(napi, struct virtnet_info, napi);
- struct sk_buff *skb = NULL;
+ void *buf = NULL;
unsigned int len, received = 0;
again:
while (received < budget &&
- (skb = vi->rvq->vq_ops->get_buf(vi->rvq, &len)) != NULL) {
- __skb_unlink(skb, &vi->recv);
- receive_skb(vi->dev, skb, len);
+ (buf = vi->rvq->vq_ops->get_buf(vi->rvq, &len)) != NULL) {
+ receive_skb(vi->dev, buf, len);
vi->num--;
received++;
}
@@ -959,6 +1006,7 @@ static void __devexit virtnet_remove(struct virtio_device *vdev)
{
struct virtnet_info *vi = vdev->priv;
struct sk_buff *skb;
+ int freed;
/* Stop all the virtqueues. */
vdev->config->reset(vdev);
@@ -970,11 +1018,17 @@ static void __devexit virtnet_remove(struct virtio_device *vdev)
}
__skb_queue_purge(&vi->send);
- BUG_ON(vi->num != 0);
-
unregister_netdev(vi->dev);
cancel_delayed_work_sync(&vi->refill);
+ if (vi->mergeable_rx_bufs || vi->big_packets) {
+ freed = vi->rvq->vq_ops->destroy_buf(vi->rvq,
+ virtio_free_pages);
+ vi->num -= freed;
+ }
+
+ BUG_ON(vi->num != 0);
+
vdev->config->del_vqs(vi->vdev);
while (vi->pages)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index fbd2ecd..aec7fe7 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -334,6 +334,29 @@ static bool vring_enable_cb(struct virtqueue *_vq)
return true;
}
+static int vring_destroy_buf(struct virtqueue *_vq, void (*callback)(void *))
+{
+ struct vring_virtqueue *vq = to_vvq(_vq);
+ void *ret;
+ unsigned int i;
+ int freed = 0;
+
+ START_USE(vq);
+
+ for (i = 0; i < vq->vring.num; i++) {
+ if (vq->data[i]) {
+ /* detach_buf clears data, so grab it now. */
+ ret = vq->data[i];
+ detach_buf(vq, i);
+ callback(ret);
+ freed++;
+ }
+ }
+
+ END_USE(vq);
+ return freed;
+}
+
irqreturn_t vring_interrupt(int irq, void *_vq)
{
struct vring_virtqueue *vq = to_vvq(_vq);
@@ -360,6 +383,7 @@ static struct virtqueue_ops vring_vq_ops = {
.kick = vring_kick,
.disable_cb = vring_disable_cb,
.enable_cb = vring_enable_cb,
+ .destroy_buf = vring_destroy_buf,
};
struct virtqueue *vring_new_virtqueue(unsigned int num,
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index 057a2e0..7b1e86c 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -71,6 +71,7 @@ struct virtqueue_ops {
void (*disable_cb)(struct virtqueue *vq);
bool (*enable_cb)(struct virtqueue *vq);
+ int (*destroy_buf)(struct virtqueue *vq, void (*callback)(void *));
};
/**
^ permalink raw reply related
* Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
From: Eric Dumazet @ 2009-11-20 6:19 UTC (permalink / raw)
To: Shirley Ma
Cc: Michael S. Tsirkin, Avi Kivity, Rusty Russell, netdev, kvm,
linux-kernel
In-Reply-To: <1258697745.7416.20.camel@localhost.localdomain>
Shirley Ma a écrit :
> This patch is generated against 2.6 git tree. I didn't break up this
> patch since it has one functionality. Please review it.
>
> Thanks
> Shirley
>
> Signed-off-by: Shirley Ma <xma@us.ibm.com>
> ------
>
> +void virtio_free_pages(void *buf)
> +{
> + struct page *page = (struct page *)buf;
> +
> + while (page) {
> + __free_pages(page, 0);
> + page = (struct page *)page->private;
> + }
> +}
> +
Interesting use after free :)
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: Tom Herbert @ 2009-11-20 6:41 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, netdev
In-Reply-To: <20091119100805.GA22938@basil.fritz.box>
>> What are the standard deadlocks? Looks like __send_remote_softirq
>> will call __smp_call_function with irq's disabled...
>
> The traditional deadlock (that was before the queue smp_call_function)
> was
>
> A B
> grab lock
> interrupts off
> spin on lock
> send IPI
> wait for specific CPU
>
> never answers because
> interrupts are off
> hangs forever
>
>
> I think with the queued smp_call_function it's better because
> the locks are only hold much shorter and that particular scenario
> is gone, but I'm not sure the problem has fully gone away.
>
> At least there are still plenty of WARN_ON( ... irqs_disabled()) in
> kernel/smp.c
>
So is send_remote_softirq also broken according to this?
^ permalink raw reply
* Re: [PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
From: Roland Dreier @ 2009-11-20 6:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Sean Hefty, David S. Miller, Linux Netdev List, Roland Dreier,
Hal Rosenstock, linux-rdma
In-Reply-To: <4B0628E0.6000404-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Any news of this patch ?
>
> We need it for 2.6.32 and also to prepare 2.6.33 with upcoming patches.
Sorry for not explicitly emailing about this patch. I applied it as
part of Sean's series, but I just added it to my 2.6.33 queue. At this
point in the release cycle it doesn't look severe enough for 2.6.32,
unless I miss something.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: Eric Dumazet @ 2009-11-20 6:49 UTC (permalink / raw)
To: Tom Herbert; +Cc: Andi Kleen, David Miller, netdev
In-Reply-To: <65634d660911192241q30a3928bg44854fc929dae218@mail.gmail.com>
Tom Herbert a écrit :
>
> So is send_remote_softirq also broken according to this?
I found this function not usable as is, anyway.
I tried to use it for XPS but failed.
Before calling it, we must put the work in a remote queue,
but if work has to be done by current cpu, we cannot remove this
work to put it in our queue. (We dont have a status from send_remote_softirq())
^ permalink raw reply
* Re: [PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
From: Eric Dumazet @ 2009-11-20 6:51 UTC (permalink / raw)
To: Roland Dreier
Cc: Sean Hefty, David S. Miller, Linux Netdev List, Roland Dreier,
Hal Rosenstock, linux-rdma
In-Reply-To: <adak4xl669z.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
Roland Dreier a écrit :
> > Any news of this patch ?
> >
> > We need it for 2.6.32 and also to prepare 2.6.33 with upcoming patches.
>
> Sorry for not explicitly emailing about this patch. I applied it as
> part of Sean's series, but I just added it to my 2.6.33 queue. At this
> point in the release cycle it doesn't look severe enough for 2.6.32,
> unless I miss something.
Its possible to get infinite loops or crashes.
I am not a RDMA user, so I personally dont care :)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [net-2.6 PATCH] ixgbe: fix compile warning without DCB
From: Jeff Kirsher @ 2009-11-20 7:07 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Jeff Kirsher, Peter P Waskiewicz Jr
When DCB is disabled, gcc warns about an unused varaible. Fixed by making
the variable only available when DCB is enabled.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index a5036f7..7cc6e93 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -240,7 +240,9 @@ static void ixgbe_unmap_and_free_tx_resource(struct ixgbe_adapter *adapter,
static inline bool ixgbe_tx_is_paused(struct ixgbe_adapter *adapter,
struct ixgbe_ring *tx_ring)
{
+#ifdef CONFIG_IXGBE_DCB
int tc;
+#endif
u32 txoff = IXGBE_TFCS_TXOFF;
#ifdef CONFIG_IXGBE_DCB
^ permalink raw reply related
* [PATCH (RESENT)] stmmac: do not fail when the timer cannot be used.
From: Giuseppe CAVALLARO @ 2009-11-20 7:16 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
If the external timer cannot be used the driver
will continue to work without mitigation.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/stmmac/stmmac_main.c | 50 ++++++++++++++++++++----------------
drivers/net/stmmac/stmmac_timer.h | 1 +
2 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index c2f14dc..9542995 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -416,13 +416,8 @@ static void init_dma_desc_rings(struct net_device *dev)
unsigned int txsize = priv->dma_tx_size;
unsigned int rxsize = priv->dma_rx_size;
unsigned int bfsize = priv->dma_buf_sz;
- int buff2_needed = 0;
- int dis_ic = 0;
+ int buff2_needed = 0, dis_ic = 0;
-#ifdef CONFIG_STMMAC_TIMER
- /* Using Timers disable interrupts on completion for the reception */
- dis_ic = 1;
-#endif
/* Set the Buffer size according to the MTU;
* indeed, in case of jumbo we need to bump-up the buffer sizes.
*/
@@ -437,6 +432,11 @@ static void init_dma_desc_rings(struct net_device *dev)
else
bfsize = DMA_BUFFER_SIZE;
+#ifdef CONFIG_STMMAC_TIMER
+ /* Disable interrupts on completion for the reception if timer is on */
+ if (likely(priv->tm->enable))
+ dis_ic = 1;
+#endif
/* If the MTU exceeds 8k so use the second buffer in the chain */
if (bfsize >= BUF_SIZE_8KiB)
buff2_needed = 1;
@@ -809,20 +809,22 @@ static void stmmac_tx(struct stmmac_priv *priv)
static inline void stmmac_enable_irq(struct stmmac_priv *priv)
{
-#ifndef CONFIG_STMMAC_TIMER
- writel(DMA_INTR_DEFAULT_MASK, priv->dev->base_addr + DMA_INTR_ENA);
-#else
- priv->tm->timer_start(tmrate);
+#ifdef CONFIG_STMMAC_TIMER
+ if (likely(priv->tm->enable))
+ priv->tm->timer_start(tmrate);
+ else
#endif
+ writel(DMA_INTR_DEFAULT_MASK, priv->dev->base_addr + DMA_INTR_ENA);
}
static inline void stmmac_disable_irq(struct stmmac_priv *priv)
{
-#ifndef CONFIG_STMMAC_TIMER
- writel(0, priv->dev->base_addr + DMA_INTR_ENA);
-#else
- priv->tm->timer_stop();
+#ifdef CONFIG_STMMAC_TIMER
+ if (likely(priv->tm->enable))
+ priv->tm->timer_stop();
+ else
#endif
+ writel(0, priv->dev->base_addr + DMA_INTR_ENA);
}
static int stmmac_has_work(struct stmmac_priv *priv)
@@ -1031,22 +1033,23 @@ static int stmmac_open(struct net_device *dev)
}
#ifdef CONFIG_STMMAC_TIMER
- priv->tm = kmalloc(sizeof(struct stmmac_timer *), GFP_KERNEL);
+ priv->tm = kzalloc(sizeof(struct stmmac_timer *), GFP_KERNEL);
if (unlikely(priv->tm == NULL)) {
pr_err("%s: ERROR: timer memory alloc failed \n", __func__);
return -ENOMEM;
}
priv->tm->freq = tmrate;
- /* Test if the HW timer can be actually used.
- * In case of failure continue with no timer. */
+ /* Test if the external timer can be actually used.
+ * In case of failure continue without timer. */
if (unlikely((stmmac_open_ext_timer(dev, priv->tm)) < 0)) {
- pr_warning("stmmaceth: cannot attach the HW timer\n");
+ pr_warning("stmmaceth: cannot attach the external timer.\n");
tmrate = 0;
priv->tm->freq = 0;
priv->tm->timer_start = stmmac_no_timer_started;
priv->tm->timer_stop = stmmac_no_timer_stopped;
- }
+ } else
+ priv->tm->enable = 1;
#endif
/* Create and initialize the TX/RX descriptors chains. */
@@ -1322,9 +1325,11 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
/* Interrupt on completition only for the latest segment */
priv->mac_type->ops->close_tx_desc(desc);
+
#ifdef CONFIG_STMMAC_TIMER
- /* Clean IC while using timers */
- priv->mac_type->ops->clear_tx_ic(desc);
+ /* Clean IC while using timer */
+ if (likely(priv->tm->enable))
+ priv->mac_type->ops->clear_tx_ic(desc);
#endif
/* To avoid raise condition */
priv->mac_type->ops->set_tx_owner(first);
@@ -2028,7 +2033,8 @@ static int stmmac_suspend(struct platform_device *pdev, pm_message_t state)
#ifdef CONFIG_STMMAC_TIMER
priv->tm->timer_stop();
- dis_ic = 1;
+ if (likely(priv->tm->enable))
+ dis_ic = 1;
#endif
napi_disable(&priv->napi);
diff --git a/drivers/net/stmmac/stmmac_timer.h b/drivers/net/stmmac/stmmac_timer.h
index f795cae..6863590 100644
--- a/drivers/net/stmmac/stmmac_timer.h
+++ b/drivers/net/stmmac/stmmac_timer.h
@@ -26,6 +26,7 @@ struct stmmac_timer {
void (*timer_start) (unsigned int new_freq);
void (*timer_stop) (void);
unsigned int freq;
+ unsigned int enable;
};
/* Open the HW timer device and return 0 in case of success */
--
1.6.0.4
^ permalink raw reply related
* Re: stmmac patches...
From: Giuseppe CAVALLARO @ 2009-11-20 7:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091119.121821.51205410.davem@davemloft.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi David,
David Miller wrote:
> Please do not intermix coding style changes with bug
> fixes.
>
> In your second patch you change the indentation of
> the arguments to ->init_rx_desc() in stmmac_suspend()
>
> Not only is this inappropriate in a bug fix patch, it
> is actually making the indentation incorrect. The
> arguments should line up to the column after the
> function argument set openning '(' on the previous
> line.
I agree with you and thanks for your feedback.
> Please fix this up and resubmit both of your patches.
I've just resent the second patch:
[PATCH (RESENT)] stmmac: do not fail when the timer cannot be used.
Let me know if I have to review something in my first patch as well.
Peppe
>
> Thank you.
> --
> 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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksGQvIACgkQ2Xo3j31MSSKodQCgopGgPPXTU+K5xESR5WXawTlc
MagAn21fS/y+pCAuiOoJVbOU5Z79yqWt
=58TT
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Jens Rosenboom @ 2009-11-20 7:49 UTC (permalink / raw)
To: Dhananjay Phadke; +Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha
In-Reply-To: <7608421F3572AB4292BB2532AE89D5658B0B95BDC9@AVEXMB1.qlogic.org>
On Thu, Nov 19, 2009 at 02:11:33PM -0800, Dhananjay Phadke wrote:
> > Sorry, I forgot to mention that all later kernels that I tested
> > including 2.6.31 and the current net-2.6 also fail, so the badness
> > comes in somewhere in between 2.6.30 and 2.6.31-rc1.
> >
> > I also noticed that the newer kernel allocate four interrupts for the
> > card instead of only one, but none of them seem to get triggered, the
> > /proc/interrupts counters all stay at zero.
>
> What firmware revision you have? Since you are saying nothing
> transmitted as well, I doubt if you have a link. Otherwise I
> would imagine kernel tries to send some neighbor solicitation
> crap as soon as you bring up interface. What does your
> "ethtool ethx" say about the link?
ethtool says "Link detected: yes" , if I try to ping a different host on the
LAN the MAC of the card appears in the FDB on the switch, so I'm pretty sure
that packets do get sent even if the kernel doesn't get a report for that
because of the broken interrupts. Firmware is 3.4.336, which is the only one
I could find from IBM Japan, the original Netxen pages seem to have been dumped
by Qlogic. :-( The firmware on the card itself is being rejected by the
kernel as too old.
> It's possible to bisect commits which applied in driver/net/netxen.
> That way you have fewer commits to rewind and remains focused on
> the driver rather than screwing scsi.
I did restrict the bisect to net/ + driver/net and still ran into trouble,
I can retry with your suggestion.
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Jens Rosenboom @ 2009-11-20 7:52 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jens Rosenboom, Dhananjay Phadke, netdev@vger.kernel.org,
Amit Salecha
In-Reply-To: <m1ocmyt2ly.fsf@fess.ebiederm.org>
On Thu, Nov 19, 2009 at 05:19:05PM -0800, Eric W. Biederman wrote:
> Jens Rosenboom <me@jayr.de> writes:
>
> > On Thu, Nov 19, 2009 at 10:07:21AM -0800, Dhananjay Phadke wrote:
> >> > My netxen 10G card stops working somewhere between 2.6.30 and 2.6.31-rc1.
> >> > With the
> >> > newer kernel I can see packets been received on the switch it is
> >> > connected to, but
> >> > the kernel doesn't report any sent packets in the interface counters and
> >> > nothing
> >> > is being received either.
> >> >
> >> > I've tried to bisect this, but only seems the end up with kernels that do
> >> > not boot
> >> > at all because some SCSI stuff goes bad.
> >>
> >> Any particular reason for using -rc1 kernel and not 2.6.31 stable kernel?
> >
> > Sorry, I forgot to mention that all later kernels that I tested
> > including 2.6.31 and the current net-2.6 also fail, so the badness
> > comes in somewhere in between 2.6.30 and 2.6.31-rc1.
> >
> > I also noticed that the newer kernel allocate four interrupts for the
> > card instead of only one, but none of them seem to get triggered, the
> > /proc/interrupts counters all stay at zero.
>
> Hmm. Have you tried disabling msi's? aka putting nomsi on the kernel
> command line.
I hadn't before but tried it now, but no difference. The kernel still seems to
allocate four interrupts:
kernel: [ 2.980300] bus: 'pci': add driver netxen_nic
kernel: [ 2.980329] bus: 'pci': driver_probe_device: matched device 0000:22:00.0 with driver netxen_nic
kernel: [ 2.980333] bus: 'pci': really_probe: probing driver netxen_nic with device 0000:22:00.0
kernel: [ 2.980446] netxen_nic 0000:22:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
kernel: [ 2.980459] netxen_nic 0000:22:00.0: setting latency timer to 64
kernel: [ 2.981505] netxen_nic 0000:22:00.0: 128MB memory map
kernel: [ 2.981611] netxen_nic 0000:22:00.0: firmware: using built-in firmware nxromimg.bin
kernel: [ 4.144018] netxen_nic 0000:22:00.0: loading firmware from nxromimg.bin
kernel: [ 10.108208] NetXen XGb XFP Board S/N IF72MK0200 Chip rev 0x25
kernel: [ 10.108211] netxen_nic 0000:22:00.0: firmware version 3.4.336
kernel: [ 10.108262] alloc irq_desc for 37 on node 0
kernel: [ 10.108265] alloc kstat_irqs on node 0
kernel: [ 10.108273] netxen_nic 0000:22:00.0: irq 37 for MSI/MSI-X
kernel: [ 10.108275] alloc irq_desc for 38 on node 0
kernel: [ 10.108277] alloc kstat_irqs on node 0
kernel: [ 10.108281] netxen_nic 0000:22:00.0: irq 38 for MSI/MSI-X
kernel: [ 10.108284] alloc irq_desc for 39 on node 0
kernel: [ 10.108286] alloc kstat_irqs on node 0
kernel: [ 10.108289] netxen_nic 0000:22:00.0: irq 39 for MSI/MSI-X
kernel: [ 10.108291] alloc irq_desc for 40 on node 0
kernel: [ 10.108293] alloc kstat_irqs on node 0
kernel: [ 10.108296] netxen_nic 0000:22:00.0: irq 40 for MSI/MSI-X
kernel: [ 10.108311] netxen_nic 0000:22:00.0: using msi-x interrupts
kernel: [ 10.108371] device: 'eth2': device_add
kernel: [ 10.108442] PM: Adding info for No Bus:eth2
kernel: [ 10.109197] netxen_nic 0000:22:00.0: eth2: XGbE port initialized
kernel: [ 10.109219] driver: '0000:22:00.0': driver_bound: bound to device 'netxen_nic'
kernel: [ 10.109226] bus: 'pci': really_probe: bound device 0000:22:00.0 to driver netxen_nic
# grep eth2 /proc/interrupts
37: 0 0 0 0 PCI-MSI-edge eth2[0]
38: 0 0 0 0 PCI-MSI-edge eth2[1]
39: 0 0 0 0 PCI-MSI-edge eth2[2]
40: 0 0 0 0 PCI-MSI-edge eth2[3]
# ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes:
Supports auto-negotiation: No
Advertised link modes: 10000baseT/Full
Advertised auto-negotiation: No
Speed: 10000Mb/s
Duplex: Full
Port: FIBRE
PHYAD: 0
Transceiver: external
Auto-negotiation: off
Supports Wake-on: d
Wake-on: d
Link detected: yes
# ethtool -i eth2
driver: netxen_nic
version: 4.0.30
firmware-version: 3.4.336
bus-info: 0000:22:00.0
# uname -rvmpi
2.6.31.6 #5 SMP Wed Nov 18 09:15:48 CET 2009 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux
> If you aren't getting interrupts it might be that your board simply
> has problems with receiving msi interrupts. That at least used to
> be common.
But it does work with the single interrupt setup in 2.6.30, is there a way to
tell the newer kernels to go back to this behaviour?
Here is the output with plain 2.6.30:
# uname -rvmpi
2.6.30 #2 SMP Wed Nov 18 16:41:15 CET 2009 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD
# grep eth2 /proc/interrupts
37: 0 0 3 4836 PCI-MSI-edge eth2[0]
# ping 10.0.21.201
PING 10.0.21.201 (10.0.21.201) 56(84) bytes of data.
64 bytes from 10.0.21.201: icmp_seq=1 ttl=255 time=1.51 ms
64 bytes from 10.0.21.201: icmp_seq=2 ttl=255 time=0.170 ms
64 bytes from 10.0.21.201: icmp_seq=3 ttl=255 time=0.156 ms
^C
--- 10.0.21.201 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.156/0.612/1.512/0.636 ms
# grep eth2 /proc/interrupts
37: 0 0 3 4985 PCI-MSI-edge eth2[0]
#
^ permalink raw reply
* Re: [net-next-2.6 PATCH] be2net:Patch to flash redboot section while firmware update.
From: Sarveshwar Bandi @ 2009-11-20 9:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091119.122356.62955207.davem@davemloft.net>
David,
This is the primary boot loader program for the firmware. It is a separate
section in the firmware image.
- Sarvesh
On 19/11/09 12:23 -0800, David Miller wrote:
> From: Sarveshwar Bandi <sarveshwarb@serverengines.com>
> Date: Thu, 19 Nov 2009 14:18:43 +0530
>
> > Please apply patch to update redboot section while firmware update. Code
> > checks if section needs to be updated before actually doing it.
> >
> > Signed-off-by: Sarveshwar Bandi <sarveshwarb@serverengines.com>
>
> What is this redboot section all about?
> --
> 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: [net-next-2.6 PATCH v2] allow access to sysfs_groups member
From: Kurt Van Dijck @ 2009-11-20 10:21 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: David Miller, netdev
In-Reply-To: <m1vdh6t2y6.fsf@fess.ebiederm.org>
On Thu, Nov 19, 2009 at 05:11:45PM -0800, Eric W. Biederman wrote:
> Kurt Van Dijck <kurt.van.dijck@eia.be> writes:
>
> > On Wed, Nov 18, 2009 at 01:08:59PM -0800, David Miller wrote:
> >>
> >> Unfortunately, the code in this function is much different
> >> in net-next-2.6 which is where I want to add this, and your
> >> patch doesn't apply.
> >>
> >> Please rebase your patch on that tree, thank you.
> > As I mentioned, I'm not experienced with using git yet.
> > Is there a fine manual I can inspect? I get lost in the man-pages.
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
>
> Should get you started.
$ git pull git://git.kernel.... master
did the job today. It took me a while
>
> In this case please look at how I modified the bonding driver to do
> what you are trying to do. That is the conflict in net-next and
> I think it was actually less code.
It _is_ less code (does a little less too :-) ).
It solves the problem anyway. I'll stop with my patch.
Thanks.
Kurt
^ permalink raw reply
* Re: Network hangs with 2.6.30.5
From: Evgeniy Polyakov @ 2009-11-20 12:04 UTC (permalink / raw)
To: David Miller
Cc: ilpo.jarvinen, jarkao2, holger.hoffstaette, netdev, eric.dumazet
In-Reply-To: <20091119.154038.194307613.davem@davemloft.net>
Hi.
On Thu, Nov 19, 2009 at 03:40:38PM -0800, David Miller (davem@davemloft.net) wrote:
> >> I also looked through all the TCP commits in 2.6.29 to 2.6.30
> >> and I could not find anything else that might cause stalls with
> >> time-wait recycled connections.
> >
> > What about the more than 64k connections change a9d8f9110d7e953c2f2 (or
> > its fixes), it might be another possibility? ...It certainly does
> > something related to reuse and happens to be in the correct time frame...
> > (I've added Evgeniy).
>
> So I've been studying this one quite a bit.
>
> This change could only cause problems in timewait recycling if it:
>
> 1) Would accept using a bind bucket that previously it would not
>
> 2) Caused socket corruption due to bad locking
>
> And I can find neither problem with the Evgeniy's bind changes.
>
> So we've back to square one I think.
Wasn't solution found for this problem, I recall related discussion
recently, or should I dig deeper into this one?
--
Evgeniy Polyakov
^ permalink raw reply
* Compile Error for TI Davinci
From: Govindarajan, Sriramakrishnan @ 2009-11-20 12:06 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com,
Subrahmanya, Chaithrika
David,
Patch for "TI DaVinci EMAC: Clear statistics register properly"(commit- 0fe7463a35aadfaf22d1ca58325ab3851b8d757c on net-next) has dependency on
Patch "TI DaVinci EMAC: Minor macro related updates "(commit - 69ef9694099802f7feeb23182dfb869e7c5f76f0 on net-next).
The first patch has been pushed upstream while the later still remains on
Net-next. Due to the dependency between these two, we are seeing compilation
Failure when we build for Davinci.
Can you please push "TI DaVinci EMAC: Minor macro related updates" - 69ef9694099802f7feeb23182dfb869e7c5f76f0 up-stream .
Regards
Sriram
^ permalink raw reply
* Re: Network hangs with 2.6.30.5
From: Ilpo Järvinen @ 2009-11-20 12:09 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: David Miller, jarkao2, holger.hoffstaette, Netdev, eric.dumazet
In-Reply-To: <20091120120452.GA11462@ioremap.net>
On Fri, 20 Nov 2009, Evgeniy Polyakov wrote:
> On Thu, Nov 19, 2009 at 03:40:38PM -0800, David Miller (davem@davemloft.net) wrote:
> > >> I also looked through all the TCP commits in 2.6.29 to 2.6.30
> > >> and I could not find anything else that might cause stalls with
> > >> time-wait recycled connections.
> > >
> > > What about the more than 64k connections change a9d8f9110d7e953c2f2 (or
> > > its fixes), it might be another possibility? ...It certainly does
> > > something related to reuse and happens to be in the correct time frame...
> > > (I've added Evgeniy).
> >
> > So I've been studying this one quite a bit.
> >
> > This change could only cause problems in timewait recycling if it:
> >
> > 1) Would accept using a bind bucket that previously it would not
> >
> > 2) Caused socket corruption due to bad locking
> >
> > And I can find neither problem with the Evgeniy's bind changes.
> >
> > So we've back to square one I think.
>
> Wasn't solution found for this problem, I recall related discussion
> recently, or should I dig deeper into this one?
Nothing that I know off (but that's not too reassuring I'd say). IIRC,
there were two independent problems same looking problems and one of them
turned out to be related to something else while the other problem
withstands but that guy's hw broke so the test case will no longer be
available or something like that.
--
i.
^ permalink raw reply
* Re: [RFC-PATCH] libiscsi dhcp handler
From: Dan Carpenter @ 2009-11-20 13:29 UTC (permalink / raw)
To: Rakesh Ranjan
Cc: David Miller, michaelc, open-iscsi, netdev, linux-kernel,
James.Bottomley, kxie
In-Reply-To: <4B01577E.2020003@chelsio.com>
On 11/16/09, Rakesh Ranjan <rakesh@chelsio.com> wrote:
> David Miller wrote:
>> From: Rakesh Ranjan <rakesh@chelsio.com>
>> Date: Mon, 16 Nov 2009 18:41:49 +0530
>>
>>> Herein attached patches to support dhcp based provisioning for iSCSI
>>> offload capable cards. I have made dhcp code as generic as possible,
>>> please go through the code. Based on the feedback I will submit final
>>> version of these patches.
>>
>> You can't really add objects to the build before the patch that
>> adds the source for that object.
>>
>
> Hi david,
>
> Fixed patch attached.
>
> Regards
> Rakesh Ranjan
>
The header file changes cause warnings in allmodconfig.
CC [M] drivers/scsi/be2iscsi/be_iscsi.o
+In file included from drivers/scsi/be2iscsi/be_iscsi.c:21:
+include/scsi/libiscsi.h:445: warning: ‘struct net_device’ declared
inside parameter list
+include/scsi/libiscsi.h:445: warning: its scope is only this
definition or declaration, which is probably not what you want
+include/scsi/libiscsi.h:447: warning: ‘struct sk_buff’ declared
inside parameter list
+include/scsi/libiscsi.h:447: warning: ‘struct net_device’ declared
inside parameter list
regards,
dan carpenter
^ 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