* Re: Debounce code vs. dma_sync_single_range_for_cpu() and e100 driver.
From: David Miller @ 2009-07-14 19:38 UTC (permalink / raw)
To: khc; +Cc: netdev
In-Reply-To: <m3d483m53q.fsf@intrepid.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Tue, 14 Jul 2009 21:34:01 +0200
> Well, e100 driver uses streaming mapping for it's RX/TX buffers as well
> as for the descriptors. Now it gets tricky - RX ring descriptors can be
> written by the device at any time (when completing RX) and at the same
> time the CPU has to be able to check the descriptor's status. It seems
> it can't be formally done with the streaming DMA API, since it doesn't
> provide invalidate and flush operations, it's rather about transfering
> control.
>
> I guess the coherent/consistent allocations should be used for this
> purpose (= uncached RAM pages on IXP4xx if I understand it correctly).
>
> Now that I know the inner working of DMA API the attached patch "fixes"
> the e100 problems, but it still doesn't seem to be a valid use of the
> API.
E100's use of streaming mappings for RX descriptors is a bug, it
should be using consistent mappings for sure.
And it's especially buggy if it isn't doing DMA API sync calls before
looking at descriptor fields, as your patch seems to cure.
^ permalink raw reply
* [PATCH net-next] Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits
From: Jarek Poplawski @ 2009-07-14 19:41 UTC (permalink / raw)
To: David Miller
Cc: Paweł Staszewski, Linux Network Development list,
Robert Olsson, Jorge Boncompte [DTI2]
In-Reply-To: <4A565449.4050403@itcare.pl>
On Thu, Jul 09, 2009 at 10:34:17PM +0200, Paweł Staszewski wrote:
> Jarek Poplawski pisze:
>> On Wed, Jul 08, 2009 at 12:56:13AM +0200, Paweł Staszewski wrote:
...
>>> Also today i have many messages in dmesg like this:
>>> Fix inflate_threshold_root. Now=25 size=11 bits
>>> :)
>>>
>>
>> This is something new and a bit surprising to me: the same threshold
>> in previous tests didn't generate this? Do you mean more than: "Fix
>> inflate_threshold_root. Now=15 size=11 bits" before?
>>
>>
> Yes. Sorry for that - this info was not all the day but only 5 minutes
> when i was making tests.
> This info was reported only when all iBGP peers was down/up fast.
>
>>> And after tune :
>>> /sys/module/fib_trie/parameters/inflate_threshold_root
>>> no more info :)
>>>
>>
>> With what value?
>>
>>
> When i set 35 as inflate_threshold_root there was no info even if all
> iBGP peers was down/up.
So it looks like the patch tested earlier could be still useful; after
changing the inflate_threshold_root it seems these warnings should be
very rare but there is no reason to alarm users with something they
can't fix optimally, anyway.
Thanks,
Jarek P.
--------------------->
ipv4: Fix inflate_threshold_root automatically
During large updates there could be triggered warnings like: "Fix
inflate_threshold_root. Now=25 size=11 bits" if inflate() of the root
node isn't finished in 10 loops. It should be much rarer now, after
changing the threshold from 15 to 25, and a temporary problem, so
this patch tries to handle it automatically using a fix variable to
increase by one inflate threshold for next root resizes (up to the 35
limit, max fix = 10). The fix variable is decreased when root's
inflate() finishes below 7 loops (even if some other, smaller table/
trie is updated -- for simplicity the fix variable is global for now).
Reported-by: Pawel Staszewski <pstaszewski@itcare.pl>
Reported-by: Jorge Boncompte [DTI2] <jorge@dti2.net>
Tested-by: Pawel Staszewski <pstaszewski@itcare.pl>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
diff -Nurp a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
--- a/net/ipv4/fib_trie.c 2009-07-13 13:32:53.000000000 +0200
+++ b/net/ipv4/fib_trie.c 2009-07-13 15:16:18.000000000 +0200
@@ -327,6 +327,8 @@ static const int inflate_threshold = 50;
static const int halve_threshold_root = 15;
static const int inflate_threshold_root = 25;
+static int inflate_threshold_root_fix;
+#define INFLATE_FIX_MAX 10 /* a comment in resize() */
static void __alias_free_mem(struct rcu_head *head)
{
@@ -617,7 +619,8 @@ static struct node *resize(struct trie *
/* Keep root node larger */
if (!tn->parent)
- inflate_threshold_use = inflate_threshold_root;
+ inflate_threshold_use = inflate_threshold_root +
+ inflate_threshold_root_fix;
else
inflate_threshold_use = inflate_threshold;
@@ -641,15 +644,27 @@ static struct node *resize(struct trie *
}
if (max_resize < 0) {
- if (!tn->parent)
- pr_warning("Fix inflate_threshold_root."
- " Now=%d size=%d bits\n",
- inflate_threshold_root, tn->bits);
- else
+ if (!tn->parent) {
+ /*
+ * It was observed that during large updates even
+ * inflate_threshold_root = 35 might be needed to avoid
+ * this warning; but it should be temporary, so let's
+ * try to handle this automatically.
+ */
+ if (inflate_threshold_root_fix < INFLATE_FIX_MAX)
+ inflate_threshold_root_fix++;
+ else
+ pr_warning("Fix inflate_threshold_root."
+ " Now=%d size=%d bits fix=%d\n",
+ inflate_threshold_root, tn->bits,
+ inflate_threshold_root_fix);
+ } else {
pr_warning("Fix inflate_threshold."
" Now=%d size=%d bits\n",
inflate_threshold, tn->bits);
- }
+ }
+ } else if (max_resize > 3 && !tn->parent && inflate_threshold_root_fix)
+ inflate_threshold_root_fix--;
check_tnode(tn);
^ permalink raw reply
* Re: [TCP_CA_CWR] Causes for entering TCP_CA_CWR state with 0 retransmissions
From: Yinglin Sun @ 2009-07-14 19:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090714.121528.15246520.davem@davemloft.net>
On Tue, Jul 14, 2009 at 3:15 PM, David Miller<davem@davemloft.net> wrote:
> From: Yinglin Sun <yinglinsun@cs.pitt.edu>
> Date: Tue, 14 Jul 2009 15:12:16 -0400
>
>> I use the total number of retransmissions reported by tcp_info. The
>> field name is tcpi_total_retrans. From the kernel source code, I found
>> that this number is for both fast retransmit and timeout
>> retransmissions. On the other hand, if fast retransmission happened,
>> ca_state should be TCP_CA_Recovery or TCP_CA_Disorder, but it's
>> TCP_CA_CWR.
>
> Great, that if you're reading the code you also see that there
> are many code paths that invoke tcp_enter_cwr() that can occur
> without any retransmissions. :-)
>
> One such case is when ECN congestion notification bits are
> seen in an ACK packet.
>
Hi David,
Thanks for your reminding. I have checked all paths to
tcp_enter_cwr(). Two of them are FRTO and ECN. Both frto and ECN on my
sender and receiver are NOT enabled, so these two are not causes.
Another one is tcp_transmit_skb(). It seems that tcp_transmit_skb
detects if TX Queue is full. If so, it calls tcp_enter_cwr. I double
checked these invocation paths. If I found all paths, the cause for
me is that TX Q is full, that is, local congestion. But it is also
possible that I missed other possible causes. Do you have any idea
about other invocation to tecp_enter_cwr?
Thanks a lot.
Yinglin
^ permalink raw reply
* Re: [TCP_CA_CWR] Causes for entering TCP_CA_CWR state with 0 retransmissions
From: David Miller @ 2009-07-14 19:53 UTC (permalink / raw)
To: yinglinsun; +Cc: netdev
In-Reply-To: <46bf9ede0907141249x7823c199uf3867b4d8284eb1c@mail.gmail.com>
From: Yinglin Sun <yinglinsun@cs.pitt.edu>
Date: Tue, 14 Jul 2009 15:49:52 -0400
> Do you have any idea about other invocation to tecp_enter_cwr?
I really think I've helped you as much as I could as this
point, you can read the code as easily as I could and that's
all that I would do to answer your question. I haven't
memorized this stuff nor do I remember things like "all the
code patchs that invoke function X"
^ permalink raw reply
* Re: [TCP_CA_CWR] Causes for entering TCP_CA_CWR state with 0 retransmissions
From: Yinglin Sun @ 2009-07-14 19:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090714.125341.104344345.davem@davemloft.net>
On Tue, Jul 14, 2009 at 3:53 PM, David Miller<davem@davemloft.net> wrote:
> From: Yinglin Sun <yinglinsun@cs.pitt.edu>
> Date: Tue, 14 Jul 2009 15:49:52 -0400
>
>> Do you have any idea about other invocation to tecp_enter_cwr?
>
> I really think I've helped you as much as I could as this
> point, you can read the code as easily as I could and that's
> all that I would do to answer your question. I haven't
> memorized this stuff nor do I remember things like "all the
> code patchs that invoke function X"
>
David, I'm sorry. You are right. I shouldn't ask question like that.
You have given me enough hints about my questions. My fault.
Thanks again.
Yinglin
^ permalink raw reply
* Re: [GIT]: Networking
From: Alan Cox @ 2009-07-14 20:12 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel, greg
In-Reply-To: <20090714.123405.181074517.davem@davemloft.net>
On Tue, 14 Jul 2009 12:34:05 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: Tue, 14 Jul 2009 20:31:23 +0100
>
> >> 8) Locking fix in TTY based networking drivers, from Ralf Baechle.
> >
> > I thought we had established that this one was wrong following further
> > discussion. The tty drivers that were calling up from IRQ handlers have
> > been fixed by the cull of bogus tty->low_latency setting.
>
> Where was this change made?
>
> At a minimum it likely needs to be added to the -stable trees.
No - the fix that needs to be in the stable trees is the one removing the
bogus tty->low_latency settings. The standard tty layer blows up in all
sorts of other ways with these driver bugs and I thought they'd been
pushed back into -stable. Will check with GregKH as I think they went via
his tree.
^ permalink raw reply
* Re: [GIT]: Networking
From: David Miller @ 2009-07-14 20:15 UTC (permalink / raw)
To: alan; +Cc: torvalds, akpm, netdev, linux-kernel, greg
In-Reply-To: <20090714211226.6d653016@lxorguk.ukuu.org.uk>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Tue, 14 Jul 2009 21:12:26 +0100
> On Tue, 14 Jul 2009 12:34:05 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
>> At a minimum it likely needs to be added to the -stable trees.
>
> No - the fix that needs to be in the stable trees is the one removing the
> bogus tty->low_latency settings. The standard tty layer blows up in all
> sorts of other ways with these driver bugs and I thought they'd been
> pushed back into -stable. Will check with GregKH as I think they went via
> his tree.
Understood.
I've reverted this change from the net-2.6 tree, thanks for
explaining.
Linus, please pull, this has been sorted out.
^ permalink raw reply
* Re: Debounce code vs. dma_sync_single_range_for_cpu() and e100 driver.
From: Krzysztof Halasa @ 2009-07-14 21:01 UTC (permalink / raw)
To: David Miller
Cc: netdev, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
PJ Waskiewicz, John Ronciak, e1000-devel
In-Reply-To: <20090714.123848.189674670.davem@davemloft.net>
(Added Cc:)
David Miller <davem@davemloft.net> writes:
> And it's especially buggy if it isn't doing DMA API sync calls before
> looking at descriptor fields, as your patch seems to cure.
Well, it does that but doesn't "sync for device" _after_ looking at the
RX descriptor (when the device is to own the desc again). On IXP4xx the
ownership transfer (cache flush/invalidate) happens on "sync for device"
only (which IMHO seems a bit fragile, though).
So what do we do?
Maybe you apply the workaround for 2.6.31 and I (or someone) will
convert e100 to coherent allocs for packet descriptors, post-31?
This isn't a terrible problem (x86 isn't affected), perhaps we should
leave it as is for 2.6.31 making sure it doesn't get out of sight with
the workaround in place?
Guess it's too risky for me to mess with the coherent allocs conversion
for 31, I don't know e100 code at all (and I have to leave for few weeks
on Thursday).
E100: work around the driver using streaming DMA mapping for RX descriptors.
E100 places it's RX packet descriptors inside skb->data and uses them
with bidirectional streaming DMA mapping. Unfortunately it fails to
transfer skb->data ownership to the device after it reads the
descriptor's status, breaking on non-coherent (e.g., ARM) platforms.
This have to be converted to use coherent memory for the descriptors.
Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -1762,6 +1762,9 @@ static int e100_rx_indicate(struct nic *nic, struct rx *rx,
if (ioread8(&nic->csr->scb.status) & rus_no_res)
nic->ru_running = RU_SUSPENDED;
+ pci_dma_sync_single_for_device(nic->pdev, rx->dma_addr,
+ sizeof(struct rfd),
+ PCI_DMA_BIDIRECTIONAL);
return -ENODATA;
}
^ permalink raw reply
* Re: Debounce code vs. dma_sync_single_range_for_cpu() and e100 driver.
From: David Miller @ 2009-07-14 21:05 UTC (permalink / raw)
To: khc
Cc: e1000-devel, netdev, bruce.w.allan, jesse.brandeburg,
john.ronciak, jeffrey.t.kirsher
In-Reply-To: <m38wirm119.fsf@intrepid.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Tue, 14 Jul 2009 23:01:54 +0200
> Maybe you apply the workaround for 2.6.31 and I (or someone) will
> convert e100 to coherent allocs for packet descriptors, post-31?
I think that's a good plan.
Will give a few days for Intel folks to chime in before applying
your patch for 2.6.31, but otherwise that's my plan.
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
^ permalink raw reply
* Re: [PATCH 2/2] NET: sungem, use spin_trylock_irqsave
From: David Miller @ 2009-07-14 21:10 UTC (permalink / raw)
To: jirislaby; +Cc: netdev, linux-kernel
In-Reply-To: <1247520220-31960-2-git-send-email-jirislaby@gmail.com>
From: Jiri Slaby <jirislaby@gmail.com>
Date: Mon, 13 Jul 2009 23:23:40 +0200
> - if (!spin_trylock(&gp->tx_lock)) {
> + if (!spin_trylock_irqsave(&gp->tx_lock)) {
I'm about to give you a royal flaming.
Any idea why?
(hint: type 'make' before you send patches!!!!)
^ permalink raw reply
* Re: [PATCH 2/2] NET: sungem, use spin_trylock_irqsave
From: Jiri Slaby @ 2009-07-14 21:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20090714.141020.34896663.davem@davemloft.net>
On 07/14/2009 11:10 PM, David Miller wrote:
>> - if (!spin_trylock(&gp->tx_lock)) {
>> + if (!spin_trylock_irqsave(&gp->tx_lock)) {
>
> (hint: type 'make' before you send patches!!!!)
Grr, I did but my bash_history shows that I built wrong subtree. My
apologies.
^ permalink raw reply
* [PATCH net-next] ipv4: fib_trie: Use tnode_get_child_rcu() and node_parent_rcu() in lookups
From: Jarek Poplawski @ 2009-07-14 21:20 UTC (permalink / raw)
To: David Miller
Cc: Paul E. McKenney, Paweł Staszewski,
Linux Network Development list, Robert Olsson
In-Reply-To: <20090705213232.GG8943@linux.vnet.ibm.com>
While looking for other fib_trie problems reported by Pawel Staszewski
I noticed there are a few uses of tnode_get_child() and node_parent()
in lookups instead of their rcu versions.
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
(this patch was prepared on top of my 2 today's fib_trie patches)
diff -Nurp a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
--- a/net/ipv4/fib_trie.c 2009-07-14 20:40:39.000000000 +0200
+++ b/net/ipv4/fib_trie.c 2009-07-14 22:41:26.000000000 +0200
@@ -1465,7 +1465,7 @@ static int fn_trie_lookup(struct fib_tab
cindex = tkey_extract_bits(mask_pfx(key, current_prefix_length),
pos, bits);
- n = tnode_get_child(pn, cindex);
+ n = tnode_get_child_rcu(pn, cindex);
if (n == NULL) {
#ifdef CONFIG_IP_FIB_TRIE_STATS
@@ -1600,7 +1600,7 @@ backtrace:
if (chopped_off <= pn->bits) {
cindex &= ~(1 << (chopped_off-1));
} else {
- struct tnode *parent = node_parent((struct node *) pn);
+ struct tnode *parent = node_parent_rcu((struct node *) pn);
if (!parent)
goto failed;
@@ -1813,7 +1813,7 @@ static struct leaf *trie_firstleaf(struc
static struct leaf *trie_nextleaf(struct leaf *l)
{
struct node *c = (struct node *) l;
- struct tnode *p = node_parent(c);
+ struct tnode *p = node_parent_rcu(c);
if (!p)
return NULL; /* trie with just one leaf */
^ permalink raw reply
* Re: [PATCH v2] Receive Packet Steering
From: Tom Herbert @ 2009-07-14 23:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090714.123313.186658126.davem@davemloft.net>
>
> > Right. In fact, just using the hash as the key is what you want when
> > device provides the hash (i.e. Toeplitz). The caveat is that we
> > should to prevent OOO packets when threads migrate, I think I have a
> > reasonable solution for that following your earlier suggestion.
>
> But as you found, compared to jhash, Toeplitz is expensive to compute
> and you would need to do this if implemented by monitoring transmits.
Well I'd rather not have to compute any hash on transmit. Toeplitz
could be populated in another field of skb from a saved value in the
socket struct.
>
> And furthermore, from the device perspective:
>
> 1) some (such as NIU) provide different hash values, not Toeplitz
>
> 2) it is expensive to extract this value (must enable different,
> larger, RX descriptor modes, thus more DMA traffic, etc.)
>
> I really don't think Toeplitz is a net win, to be honest.
Using the Toeplitz hash in steering lookup has given us about 10% more
maximum pps (2 different NICs), and we haven't really noticed negative
effects because of the extra descriptor overhead-- so I'm not going to
give up on it too easily! A device provided hash could probably be
used as an opaque value-- used as hash key into steering table on RX,
saved in socket structure in RX, and then sent with skb on transmit
during which it is used to update the steering table. At the socket
layer, we would just need to collect and cache values in socket
structures.
>
> > I hope to have a new patch soon for steering packets to application
> > CPU and using device hash, thanks for bugging me on it!
>
> I had no choice, as I'm giving a presentation on this stuff tomorrow
> night here in NYC :-)
Cool, do you happen to have slides.... :-)
^ permalink raw reply
* [PATCH net-next-2.6 0/2] Enable UFO on virtio-net/tap devices
From: Sridhar Samudrala @ 2009-07-15 0:20 UTC (permalink / raw)
To: David Miller, Herbert Xu, Rusty Russell, netdev
Now that the kernel handles sending/receiving of large UDP packets and can do
software UFO if the outgoing device doesn't support IP fragmentation, we can
enable this feature on virtio-net/tap devices.
[PATCH net-next-2.6 1/2] virtio-net: Allow UFO feature to be set and advertised.
[PATCH net-next-2.6 2/] tun: Allow tap device to send/receive UFO packets.
Thanks
Sridhar
^ permalink raw reply
* [PATCH net-next-2.6 1/2] virtio-net: Allow UFO feature to be set and advertised.
From: Sridhar Samudrala @ 2009-07-15 0:21 UTC (permalink / raw)
To: David Miller, Herbert Xu, Rusty Russell, netdev
[PATCH net-next-2.6 1/2] virtio-net: Allow UFO feature to be set
- Allow setting UFO on virtio-net and advertise to host.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---------------------------------------------------------
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 2a6e81d..a6f903f 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -774,6 +774,7 @@ static struct ethtool_ops virtnet_ethtool_ops = {
.set_tx_csum = virtnet_set_tx_csum,
.set_sg = ethtool_op_set_sg,
.set_tso = ethtool_op_set_tso,
+ .set_ufo = ethtool_op_set_ufo,
.get_link = ethtool_op_get_link,
};
@@ -1005,7 +1006,7 @@ static unsigned int features[] = {
VIRTIO_NET_F_GSO, VIRTIO_NET_F_MAC,
VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_UFO, VIRTIO_NET_F_HOST_TSO6,
VIRTIO_NET_F_HOST_ECN, VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6,
- VIRTIO_NET_F_GUEST_ECN, /* We don't yet handle UFO input. */
+ VIRTIO_NET_F_GUEST_ECN, VIRTIO_NET_F_GUEST_UFO,
VIRTIO_NET_F_MRG_RXBUF, VIRTIO_NET_F_STATUS, VIRTIO_NET_F_CTRL_VQ,
VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN,
VIRTIO_F_NOTIFY_ON_EMPTY,
>
^ permalink raw reply related
* [PATCH net-next-2.6 2/2] tun: Allow tap device to send/receive UFO packets.
From: Sridhar Samudrala @ 2009-07-15 0:21 UTC (permalink / raw)
To: David Miller, Herbert Xu, Rusty Russell, netdev
[PATCH net-next-2.6 2/2] tun: Allow tap device to send/receive UFO packets.
- Allow setting UFO on tap device and handle UFO packets.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---------------------------------------------------------
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index dfc1054..a998b6a 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -641,6 +641,9 @@ static __inline__ ssize_t tun_get_user(struct tun_struct *tun,
case VIRTIO_NET_HDR_GSO_TCPV6:
skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
break;
+ case VIRTIO_NET_HDR_GSO_UDP:
+ skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
+ break;
default:
tun->dev->stats.rx_frame_errors++;
kfree_skb(skb);
@@ -726,6 +729,8 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (sinfo->gso_type & SKB_GSO_TCPV6)
gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (sinfo->gso_type & SKB_GSO_UDP)
+ gso.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else
BUG();
if (sinfo->gso_type & SKB_GSO_TCP_ECN)
@@ -1073,7 +1078,8 @@ static int set_offload(struct net_device *dev, unsigned long arg)
old_features = dev->features;
/* Unset features, set them as we chew on the arg. */
features = (old_features & ~(NETIF_F_HW_CSUM|NETIF_F_SG|NETIF_F_FRAGLIST
- |NETIF_F_TSO_ECN|NETIF_F_TSO|NETIF_F_TSO6));
+ |NETIF_F_TSO_ECN|NETIF_F_TSO|NETIF_F_TSO6
+ |NETIF_F_UFO));
if (arg & TUN_F_CSUM) {
features |= NETIF_F_HW_CSUM|NETIF_F_SG|NETIF_F_FRAGLIST;
@@ -1090,6 +1096,11 @@ static int set_offload(struct net_device *dev, unsigned long arg)
features |= NETIF_F_TSO6;
arg &= ~(TUN_F_TSO4|TUN_F_TSO6);
}
+
+ if (arg & TUN_F_UFO) {
+ features |= NETIF_F_UFO;
+ arg &= ~TUN_F_UFO;
+ }
}
/* This gives the user a way to test for new features in future by
diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index 915ba57..3f5fd52 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -62,6 +62,7 @@
#define TUN_F_TSO4 0x02 /* I can handle TSO for IPv4 packets */
#define TUN_F_TSO6 0x04 /* I can handle TSO for IPv6 packets */
#define TUN_F_TSO_ECN 0x08 /* I can handle TSO with ECN bits. */
+#define TUN_F_UFO 0x10 /* I can handle UFO packets */
/* Protocol info prepended to the packets (when IFF_NO_PI is not set) */
#define TUN_PKT_STRIP 0x0001
^ permalink raw reply related
* [tcp-dsack] interface for retrieving dsack information
From: Yinglin Sun @ 2009-07-15 0:21 UTC (permalink / raw)
To: netdev
Hi,
I'm trying to count the number of unnecessary retransmissions for a
tcp connection. DSACK reports the receipt of duplicate segment to
sender, so I plan to count the duplicate transmissions reported by
DSACK as unnecessary retransmissions. My question is if there is a
nice interface, like tcp_info, which can be used for retrieving the
number of duplicate transmissions from DSACK? tcp_info structure
doesn't include such information.
Thanks a lot.
Yinglin
^ permalink raw reply
* [PATCH net-next] Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits
From: Robert Olsson @ 2009-07-15 7:43 UTC (permalink / raw)
To: Jarek Poplawski
Cc: David Miller, Paweł Staszewski,
Linux Network Development list, Robert Olsson,
Jorge Boncompte [DTI2]
In-Reply-To: <20090714194100.GA7952@ami.dom.local>
Jarek Poplawski writes:
Looks good. Maybe we're getting close to some generic solution to take
a very optimistic approach wrt thresholds for root node and adjust to
settings without the warning. Or maybe now even remove warning totally
with stata counter?
Can we even consider some other different strategy for bumping up the root
node.
We need all lookup performance we can get when we now try to route without
the route cache. And we probably need to evaluate the cost for the multiple
lookups again at least for LOCAL and MAIN when we talking routing well at
least straight-forward simple routing. (Semantic change)
I think I've got ~6.2 Gbit/s for simplex forwarding using traffic patterns
we see in/close to Internet core. This w/o route cache on our hi-end opterons
with 8 CPU cores using niu and ixgbe. I'll test again and your patches when
I'm back from vacation.
Cheers
--ro
> So it looks like the patch tested earlier could be still useful; after
> changing the inflate_threshold_root it seems these warnings should be
> very rare but there is no reason to alarm users with something they
> can't fix optimally, anyway.
>
> Thanks,
> Jarek P.
> --------------------->
> ipv4: Fix inflate_threshold_root automatically
>
> During large updates there could be triggered warnings like: "Fix
> inflate_threshold_root. Now=25 size=11 bits" if inflate() of the root
> node isn't finished in 10 loops. It should be much rarer now, after
> changing the threshold from 15 to 25, and a temporary problem, so
> this patch tries to handle it automatically using a fix variable to
> increase by one inflate threshold for next root resizes (up to the 35
> limit, max fix = 10). The fix variable is decreased when root's
> inflate() finishes below 7 loops (even if some other, smaller table/
> trie is updated -- for simplicity the fix variable is global for now).
>
> Reported-by: Pawel Staszewski <pstaszewski@itcare.pl>
> Reported-by: Jorge Boncompte [DTI2] <jorge@dti2.net>
> Tested-by: Pawel Staszewski <pstaszewski@itcare.pl>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> ---
>
> diff -Nurp a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> --- a/net/ipv4/fib_trie.c 2009-07-13 13:32:53.000000000 +0200
> +++ b/net/ipv4/fib_trie.c 2009-07-13 15:16:18.000000000 +0200
> @@ -327,6 +327,8 @@ static const int inflate_threshold = 50;
> static const int halve_threshold_root = 15;
> static const int inflate_threshold_root = 25;
>
> +static int inflate_threshold_root_fix;
> +#define INFLATE_FIX_MAX 10 /* a comment in resize() */
>
> static void __alias_free_mem(struct rcu_head *head)
> {
> @@ -617,7 +619,8 @@ static struct node *resize(struct trie *
> /* Keep root node larger */
>
> if (!tn->parent)
> - inflate_threshold_use = inflate_threshold_root;
> + inflate_threshold_use = inflate_threshold_root +
> + inflate_threshold_root_fix;
> else
> inflate_threshold_use = inflate_threshold;
>
> @@ -641,15 +644,27 @@ static struct node *resize(struct trie *
> }
>
> if (max_resize < 0) {
> - if (!tn->parent)
> - pr_warning("Fix inflate_threshold_root."
> - " Now=%d size=%d bits\n",
> - inflate_threshold_root, tn->bits);
> - else
> + if (!tn->parent) {
> + /*
> + * It was observed that during large updates even
> + * inflate_threshold_root = 35 might be needed to avoid
> + * this warning; but it should be temporary, so let's
> + * try to handle this automatically.
> + */
> + if (inflate_threshold_root_fix < INFLATE_FIX_MAX)
> + inflate_threshold_root_fix++;
> + else
> + pr_warning("Fix inflate_threshold_root."
> + " Now=%d size=%d bits fix=%d\n",
> + inflate_threshold_root, tn->bits,
> + inflate_threshold_root_fix);
> + } else {
> pr_warning("Fix inflate_threshold."
> " Now=%d size=%d bits\n",
> inflate_threshold, tn->bits);
> - }
> + }
> + } else if (max_resize > 3 && !tn->parent && inflate_threshold_root_fix)
> + inflate_threshold_root_fix--;
>
> check_tnode(tn);
>
^ permalink raw reply
* Re: sk_lock: inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage
From: Wu Fengguang @ 2009-07-15 7:45 UTC (permalink / raw)
To: David Miller
Cc: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20090714.090432.13343695.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Wed, Jul 15, 2009 at 12:04:32AM +0800, David Miller wrote:
> From: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
> Date: Fri, 10 Jul 2009 16:02:47 +0800
>
> > On Fri, Jul 10, 2009 at 04:00:17PM +0800, Wu Fengguang wrote:
> >>
> >> The (sk_allocation & ~__GFP_WAIT) cases should be rare, but I guess
> >> the networking code shall do it anyway, because sk_allocation defaults
> >> to GFP_KERNEL. It seems that currently the networking code simply uses
> >> a lot of GFP_ATOMIC, do they really mean "I cannot sleep"?
> >
> > Yep because they're done from softirq context.
>
> Yes, this is the core issue.
Yes, that's general true. But..
> All of Wu's talk about how "GFP_ATOMIC will wake up kswapd and
> therefore can succeed just as well as GFP_KERNEL" is not relevant,
> because GFP_ATOMIC means sleeping is not allowed.
We are talking about tcp_send_fin() here, which can sleep.
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* [PATCH 1/2] net/can bugfix: use after free bug in can protocol drivers
From: Lothar Waßmann @ 2009-07-15 9:10 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Oliver Hartkopp, Herbert Xu, davem, netdev, urs.thuermann,
Urs Thuermann
In-Reply-To: <4A5CC626.8020800@grandegger.com>
Fix a use after free bug in can protocol drivers
The release functions of the can protocol drivers lack a call to
sock_orphan() which leads to referencing freed memory under certain
circumstances.
This patch fixes a bug reported here:
https://lists.berlios.de/pipermail/socketcan-users/2009-July/000985.html
Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
Acked-by: Oliver Hartkopp <oliver@hartkopp.net>
---
diff -upr linux-2.6.30/net/can/bcm.c linux-2.6.30-karo/net/can/bcm.c
--- linux-2.6.30/net/can/bcm.c 2009-06-10 05:05:27.000000000 +0200
+++ linux-2.6.30-karo/net/can/bcm.c 2009-07-14 14:13:01.000000000 +0200
@@ -1469,6 +1469,9 @@ static int bcm_release(struct socket *so
bo->ifindex = 0;
}
+ sock_orphan(sk);
+ sock->sk = NULL;
+
release_sock(sk);
sock_put(sk);
diff -upr linux-2.6.30/net/can/raw.c linux-2.6.30-karo/net/can/raw.c
--- linux-2.6.30/net/can/raw.c 2009-06-10 05:05:27.000000000 +0200
+++ linux-2.6.30-karo/net/can/raw.c 2009-07-14 14:13:07.000000000 +0200
@@ -306,6 +306,9 @@ static int raw_release(struct socket *so
ro->bound = 0;
ro->count = 0;
+ sock_orphan(sk);
+ sock->sk = NULL;
+
release_sock(sk);
sock_put(sk);
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH 2/2] net/can: add module alias to can protocol drivers
From: Lothar Waßmann @ 2009-07-15 9:12 UTC (permalink / raw)
To: netdev
Cc: Oliver Hartkopp, Herbert Xu, davem, Wolfgang Grandegger,
urs.thuermann, Urs Thuermann
In-Reply-To: <19037.40189.520170.8242@ipc1.ka-ro>
Add appropriate MODULE_ALIAS() to facilitate autoloading of can protocol drivers
Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
Acked-by: Oliver Hartkopp <oliver@hartkopp.net>
---
diff -ur linux-2.6.30/net/can/bcm.c linux-2.6.30-karo/net/can/bcm.c
--- linux-2.6.30-karo.orig/net/can/bcm.c 2009-07-15 10:58:51.000000000 +0200
+++ linux-2.6.30-karo/net/can/bcm.c 2009-07-14 13:48:52.000000000 +0200
@@ -75,6 +75,7 @@
MODULE_DESCRIPTION("PF_CAN broadcast manager protocol");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Oliver Hartkopp <oliver.hartkopp@volkswagen.de>");
+MODULE_ALIAS("can-proto-2");
/* easy access to can_frame payload */
static inline u64 GET_U64(const struct can_frame *cp)
diff -ur linux-2.6.30/net/can/raw.c linux-2.6.30-karo/net/can/raw.c
--- linux-2.6.30-karo.orig/net/can/raw.c 2009-07-15 10:59:03.000000000 +0200
+++ linux-2.6.30-karo/net/can/raw.c 2009-07-14 13:48:52.000000000 +0200
@@ -62,6 +62,7 @@
MODULE_DESCRIPTION("PF_CAN raw protocol");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+MODULE_ALIAS("can-proto-1");
#define MASK_ALL 0
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: Belkin F5D5055 not really working with the asix driver
From: Christian Tramnitz @ 2009-07-15 9:17 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA; +Cc: netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1295ed070811040131p9170c37r5435750fa17a6f43-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Sorry for hijacking this really old report (and for cross-posting to USB
where I think it may belong too).
I'm having the same problem with a Belkin f5d5055 but could gather some
more details:
The adapter only refuses to work after a cold reboot (poweroff /
powerup) while it is actually working when hotplugged into a running
system (including consecutive reboots).
Does anyone have an idea what could be causing this?
The same system (and components like cable, switches) were running fine
with an AX88772 based adapter, but the AX88178 seems to behave
differently...
Thanks,
Christian
Pantelis Koukousoulas wrote:
> Hi, I got a belkin f5d5055 usb 2.0 gigabit adapter that should be
> supported by usbnet + the asix driver, still although recognized it
> doesn't actually work. More specifically, the card is recognized, the
> interface is created and brought up etc only no packets flow from/to
> the device.
>
> I tried the exact same card, cable and router combination with windows
> and it works fine (ping, dhcp everything) so I suspect the driver
> might be the problem.
>
> I recompiled with debug information enabled and I attach the trace,
> hoping it will help.
> I can also provide usbmon traces and a usbsnoop trace from the windows
> machine where it works if needed.
>
> Unfortunately I don't have the time to dig through the datasheets/code
> to fix the problem myself :(
>
> Thanks in advance.
>
> P.s., Please CC me in any replies since I 'm not subscribed in this list
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* why some packets lost during transmission?
From: jon_zhou @ 2009-07-15 9:17 UTC (permalink / raw)
To: netdev
In-Reply-To: <A353FA76-7D71-425F-BD67-FEE6DC26EF6F@cs.uni-bonn.de>
hi
I try to send packets like this:
for (i=0;i<loop;i++)
{
dev->hard_start_xmit(my_skb,dev);
}
the 'dev' point to network device.
but too many packets lost if the 'loop' is big(i.e. 5000), I suspect the tx buffer of the NIC is full,but the driver does not print any related info.
how does the upper layer(i.e.arp,qdisc) handle this situation?
Thanks&Regards,
zhou rui
^ permalink raw reply
* Re: [patch 1/3] net: serialize hrtimer callback in sched_cbq
From: Oliver Hartkopp @ 2009-07-15 9:56 UTC (permalink / raw)
To: David Miller, tglx; +Cc: netdev, linux-kernel, kaber, peterz
In-Reply-To: <20090714.090055.56906831.davem@davemloft.net>
David Miller wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> Date: Tue, 14 Jul 2009 10:55:14 +0200 (CEST)
>
>> David,
>>
>> On Sun, 12 Jul 2009, David Miller wrote:
>>
>>> What should probably happen is that the hrtimer merely fires off work
>>> at software interrupt context (perhaps a tasklet or similar), and that
>>> software interrupt code take the qdisc's root lock throughout it's
>>> execution.
>> Sigh, I almost expected that the removal of the callback modes will
>> fire back some day.
>
> Well this makes hrtimers decidedly less useful for networking and we
> have a ton of bugs right now, basically in every hrtimer used by the
> networking currently.
The CAN stuff is clean in this topic. See below.
>
> The only way we can use them, as things currently stand, is as
> triggers for softirq work.
>
> Is it really that troublesome to provide this kind of facility
> generically, rather than having various subsystems replicate such code
> where they want to use hrtimers and are restricted to softirqs?
Indeed this had been my concerns also, when i moved the hrtimer usage in a CAN
protocol to use tasklets.
("can: update can-bcm for hrtimer hardirq callbacks")
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6e5c172cf7ca1ab878cc6a6a4c1d52fef60f3ee0
due to
("hrtimer: removing all ur callback modes")
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ca109491f612aab5c8152207631c0444f63da97f
I was not very amused that time and wanted to NACK that change, but Linus said:
"Quite frankly, your NAK doesn't matter.
We've had too many bugs in hrtimers. They _will_ get simplified."
(http://lkml.indiana.edu/hypermail/linux/kernel/0812.1/00218.html)
Thomas, is there chance to get this nice simple possibility back to invoke at
least a hrtimer for SOFT_IRQ context additional to the current functionality??
I would expect this to save lot's of tasklet code that is - and will be -
created due to the lack of the hrtimers softirq capability ...
FWIK there were really many callback modes before (per-cpu stuff and so), that
were probably too much. But having a SOFT_IRQ callback mode again would really
help.
Regards,
Oliver
^ permalink raw reply
* [PATCH] netfilter: ebtables: Use print_mac instead of own function
From: Tobias Klauser @ 2009-07-15 10:55 UTC (permalink / raw)
To: bart.de.schuymer, shemminger, kaber, davem, ebtables-devel,
netfilter-devel
Cc: netdev, Tobias Klauser
ebt_log uses its own implementation of print_mac to print MAC addresses.
This patch converts it to use print_mac from linux/if_ether.h
Signed-off-by: Tobias Klauser <klto@zhaw.ch>
---
net/bridge/netfilter/ebt_log.c | 31 +++++++++++--------------------
1 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/net/bridge/netfilter/ebt_log.c b/net/bridge/netfilter/ebt_log.c
index a94f3cc..70fd072 100644
--- a/net/bridge/netfilter/ebt_log.c
+++ b/net/bridge/netfilter/ebt_log.c
@@ -12,6 +12,7 @@
#include <linux/ip.h>
#include <linux/in.h>
#include <linux/if_arp.h>
+#include <linux/if_ether.h>
#include <linux/spinlock.h>
#include <net/netfilter/nf_log.h>
#include <linux/ipv6.h>
@@ -50,14 +51,6 @@ struct arppayload
unsigned char ip_dst[4];
};
-static void print_MAC(const unsigned char *p)
-{
- int i;
-
- for (i = 0; i < ETH_ALEN; i++, p++)
- printk("%02x%c", *p, i == ETH_ALEN - 1 ? ' ':':');
-}
-
static void
print_ports(const struct sk_buff *skb, uint8_t protocol, int offset)
{
@@ -86,16 +79,16 @@ ebt_log_packet(u_int8_t pf, unsigned int hooknum,
const char *prefix)
{
unsigned int bitmask;
+ DECLARE_MAC_BUF(macbuf);
spin_lock_bh(&ebt_log_lock);
- printk("<%c>%s IN=%s OUT=%s MAC source = ", '0' + loginfo->u.log.level,
- prefix, in ? in->name : "", out ? out->name : "");
-
- print_MAC(eth_hdr(skb)->h_source);
- printk("MAC dest = ");
- print_MAC(eth_hdr(skb)->h_dest);
-
- printk("proto = 0x%04x", ntohs(eth_hdr(skb)->h_proto));
+ printk("<%c>%s IN=%s OUT=%s MAC source = %s",
+ '0' + loginfo->u.log.level, prefix,
+ in ? in->name : "", out ? out->name : "",
+ print_mac(macbuf, eth_hdr(skb)->h_source));
+ printk(" MAC dest = %s proto = 0x%04x",
+ print_mac(macbuf, eth_hdr(skb)->h_dest),
+ ntohs(eth_hdr(skb)->h_proto));
if (loginfo->type == NF_LOG_TYPE_LOG)
bitmask = loginfo->u.log.logflags;
@@ -171,11 +164,9 @@ ebt_log_packet(u_int8_t pf, unsigned int hooknum,
printk(" INCOMPLETE ARP payload");
goto out;
}
- printk(" ARP MAC SRC=");
- print_MAC(ap->mac_src);
+ printk(" ARP MAC SRC=%s", print_mac(macbuf, ap->mac_src));
printk(" ARP IP SRC=%pI4", ap->ip_src);
- printk(" ARP MAC DST=");
- print_MAC(ap->mac_dst);
+ printk(" ARP MAC DST=%s", print_mac(macbuf, ap->mac_dst));
printk(" ARP IP DST=%pI4", ap->ip_dst);
}
}
--
1.6.0.4
^ permalink raw reply related
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