* Re: [Bugme-new] [Bug 29252] New: IPv6 doesn't work in a kvm guest.
From: David Miller @ 2011-03-09 23:58 UTC (permalink / raw)
To: akpm; +Cc: netdev, bugzilla-daemon, bugme-daemon, slash, ernstp
In-Reply-To: <20110217142517.b9919481.akpm@linux-foundation.org>
Ok, the following should address both bugs, #29252 and #30462, please
give it some testing.
--------------------
ipv6: Don't create clones of nonexthop routes forever.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=29252
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=30462
In commit d80bc0fd262ef840ed4e82593ad6416fa1ba3fc4 ("ipv6: Always
clone offlink routes.") we forced the kernel to always clone offlink
routes.
The reason we do that is to make sure we never bind an inetpeer to a
prefixed route.
The logic turned on here has existed in the tree for many years,
but was always off due to a protecting CPP define. So perhaps
it's no surprise that there is a logic bug here.
The issue is that there is nothing that stops the cloning process.
Every route call will find the same route in the same condition,
reclone it, and insert.
This causes two problems:
1) If the in6_rt_ins() call succeeds, we get tons of crap in the
routing tree.
2) If the int6_rt_ins() call fails, we get no networking to that
destination.
We've had reports of both cases.
End the loop and the failures by keying on the RTF_CACHE flag which
will only be set in the clone routes.
Reported-by: slash@ac.auone-net.jp
Reported-by: Ernst Sjöstrand <ernstp@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 904312e..8963635 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -739,8 +739,10 @@ restart:
if (!rt->rt6i_nexthop && !(rt->rt6i_flags & RTF_NONEXTHOP))
nrt = rt6_alloc_cow(rt, &fl->fl6_dst, &fl->fl6_src);
- else
+ else if (!(rt->rt6i_flags & RTF_CACHE))
nrt = rt6_alloc_clone(rt, &fl->fl6_dst);
+ else
+ goto out2;
dst_release(&rt->dst);
rt = nrt ? : net->ipv6.ip6_null_entry;
^ permalink raw reply related
* Re: [PATCH] ipv4: Cache source address in nexthop entries.
From: David Miller @ 2011-03-09 23:40 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1103100014430.2160@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Thu, 10 Mar 2011 01:32:18 +0200 (EET)
> On Wed, 9 Mar 2011, David Miller wrote:
>
>> So device address operations increment a generation ID and
>> FIB_RES_PREFSRC() checks that ID against one stored in the nexthop.
>
> Yes, may be it is better this generation ID to be global
> value for netns, because the global addresses should cause
> refresh for all nexthops on all devices. The ID should be
> matched with corresponding value in NH. Another option is
> to use per-device gen_id instead of netns gen_id but in this
> case scope-global address event should increment gen_id for all
> devices while the device_UP event will increment only
> gen_id for the concerned DEV.
>
> I.e. there are 2 variants:
I think the per-namespace ID makes the most sense.
If the whole idea of the genid is to reduce complication, trying to place
games on a per-device basis wrt. the scope cases seems to work against that
goal :-)
After I try to attack the ipv6 routing regression I added in net-2.6, I'll
take a stab at this.
Thanks!
^ permalink raw reply
* Re: [PATCH] ipv4: Cache source address in nexthop entries.
From: Julian Anastasov @ 2011-03-09 23:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110309.130817.115943793.davem@davemloft.net>
Hello,
On Wed, 9 Mar 2011, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Wed, 9 Mar 2011 02:49:49 +0200 (EET)
>
>> But we still need to propagate the address events
>> to nexthops on all devices. Even if it is slow, I see it in
>> this way (not tested):
>
> Ok, I think it is even more involved than what you propose.
>
> We have to potentially re-run inet_select_addr() on all nexthops, even
> those pointing to devices other than the one being modified, because
> when an interface loses it's last IP address we have to look for a
> source address to use on other active interfaces.
Yes. The common case is addresses to be scope
global. That means they can influence any nexthop on
any device. Only when address has scope >= LINK we can
use version that walks single table row for the same device.
In the default case we need to walk all table rows.
Additionally, it is possible same address to exist
on different devices, possibly with different scope. That is
why reacting only on "last_ip" indication when deleting IP
is not enough. May be while we delete scope-link address on the
concerned device, there can be same address as scope-link
on another device but its scope is not enough to keep
it as nh_saddr, so the right thing is to get different
IP as saddr. That is why in my version of fib_update_nh_saddrs
I don't care about "last_ip" indication. I think, my
version of fib_update_nh_saddrs is ok for IP add/del but
as I said, device UP events should recalc nh_saddr too.
In my version the logic is:
- add IP:
- check all NHs on all devices
- goal: if the added IP-scope is suitable for NH
it can replace other less-priority IPs, where the
priority depends on factors such as device, placement in
device list and scope
- if NH has same nh_saddr then nothing to do
- IP scope and DEV should be allowed for the nh_cfg_scope
to change the nh_saddr
- del IP:
- check all NHs on all devices
- goal: if the removed IP-scope was nh_saddr somewhere
then we should recalc NH, even when IP is not the
last address with same value
- if NH has different nh_saddr then nothing to do
- IP scope and DEV should be allowed for the nh_cfg_scope
to change the nh_saddr because may be this IP-scope-DEV
was used as nh_saddr
> Probably it makes sense to recompute this at use time instead of
> walking all of this stuff at every event.
Yes, it looks less dangerous.
> So device address operations increment a generation ID and
> FIB_RES_PREFSRC() checks that ID against one stored in the nexthop.
Yes, may be it is better this generation ID to be global
value for netns, because the global addresses should cause
refresh for all nexthops on all devices. The ID should be
matched with corresponding value in NH. Another option is
to use per-device gen_id instead of netns gen_id but in this
case scope-global address event should increment gen_id for all
devices while the device_UP event will increment only
gen_id for the concerned DEV.
I.e. there are 2 variants:
1. global netns gen_id:
- add/del IP, device UP => netns->gen_id ++
2. dev->gen_id:
- add/del IP with scope < LINK => increment
dev->gen_id for all devices
- add/del IP with scope >= LINK => increment
dev->gen_id only for concerned device
- device UP: increment dev->gen_id only for
concerned device
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: Network performance with small packets - continued
From: Tom Lendacky @ 2011-03-09 23:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shirley Ma, Rusty Russell, Krishna Kumar2, David Miller, kvm,
netdev, steved
In-Reply-To: <20110309215537.GA11516@redhat.com>
On Wednesday, March 09, 2011 03:56:15 pm Michael S. Tsirkin wrote:
> On Wed, Mar 09, 2011 at 02:11:07PM -0600, Tom Lendacky wrote:
> > Here are the results again with the addition of the interrupt rate that
> > occurred on the guest virtio_net device:
> >
> > Here is the KVM baseline (average of six runs):
> > Txn Rate: 87,070.34 Txn/Sec, Pkt Rate: 172,992 Pkts/Sec
> > Exits: 148,444.58 Exits/Sec
> > TxCPU: 2.40% RxCPU: 99.35%
> > Virtio1-input Interrupts/Sec (CPU0/CPU1): 5,154/5,222
> > Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
> >
> > About 42% of baremetal.
> >
> > Delayed freeing of TX buffers (average of six runs):
> > Txn Rate: 90,886.19 Txn/Sec, Pkt Rate: 180,571 Pkts/Sec
> > Exits: 142,681.67 Exits/Sec
> > TxCPU: 2.78% RxCPU: 99.36%
> > Virtio1-input Interrupts/Sec (CPU0/CPU1): 4,796/4,908
> > Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
> >
> > About a 4% increase over baseline and about 44% of baremetal.
>
> Looks like delayed freeing is a good idea generally.
> Is this my patch? Yours?
These results are for my patch, I haven't had a chance to run your patch yet.
>
> > Delaying kick_notify (kick every 5 packets -average of six runs):
> > Txn Rate: 107,106.36 Txn/Sec, Pkt Rate: 212,796 Pkts/Sec
> > Exits: 102,587.28 Exits/Sec
> > TxCPU: 3.03% RxCPU: 99.33%
> > Virtio1-input Interrupts/Sec (CPU0/CPU1): 4,200/4,293
> > Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
> >
> > About a 23% increase over baseline and about 52% of baremetal.
>
> > Delaying kick_notify and pinning virtio1-input to CPU0 (average of six
runs):
> What exactly moves the interrupt handler between CPUs?
> irqbalancer? Does it matter which CPU you pin it to?
> If yes, do you have any idea why?
Looking at the guest, irqbalance isn't running and the smp_affinity for the
irq is set to 3 (both CPUs). It could be that irqbalance would help in this
situation since it would probably change the smp_affinity mask to a single CPU
and remove the irq lock contention (I think the last used index patch would be
best though since it will avoid the extra irq injections). I'll kick off a
run with irqbalance running.
As for which CPU the interrupt gets pinned to, that doesn't matter - see
below.
>
> Also, what happens without delaying kick_notify
> but with pinning?
Here are the results of a single "baseline" run with the IRQ pinned to CPU0:
Txn Rate: 108,212.12 Txn/Sec, Pkt Rate: 214,994 Pkts/Sec
Exits: 119,310.21 Exits/Sec
TxCPU: 9.63% RxCPU: 99.47%
Virtio1-input Interrupts/Sec (CPU0/CPU1):
Virtio1-output Interrupts/Sec (CPU0/CPU1):
and CPU1:
Txn Rate: 108,053.02 Txn/Sec, Pkt Rate: 214,678 Pkts/Sec
Exits: 119,320.12 Exits/Sec
TxCPU: 9.64% RxCPU: 99.42%
Virtio1-input Interrupts/Sec (CPU0/CPU1): 13,608/0
Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/13,830
About a 24% increase over baseline.
>
> > Txn Rate: 153,696.59 Txn/Sec, Pkt Rate: 305,358 Pkts/Sec
> > Exits: 62,603.37 Exits/Sec
> > TxCPU: 3.73% RxCPU: 98.52%
> > Virtio1-input Interrupts/Sec (CPU0/CPU1): 11,564/0
> > Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
> >
> > About a 77% increase over baseline and about 74% of baremetal.
>
> Hmm we get about 20 packets per interrupt on average.
> That's pretty decent. The problem is with exits.
> Let's try something adaptive in the host?
^ permalink raw reply
* Re: Network performance with small packets - continued
From: Tom Lendacky @ 2011-03-09 22:57 UTC (permalink / raw)
To: Shirley Ma
Cc: Michael S. Tsirkin, Rusty Russell, Krishna Kumar2, David Miller,
kvm, netdev, steved
In-Reply-To: <1299710712.25664.175.camel@localhost.localdomain>
On Wednesday, March 09, 2011 04:45:12 pm Shirley Ma wrote:
> Hello Tom,
>
> Do you also have Rusty's virtio stat patch results for both send queue
> and recv queue to share here?
Let me see what I can do about getting the data extracted, averaged and in a
form that I can put in an email.
>
> Thanks
> Shirley
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" 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: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: James Morris @ 2011-03-09 22:53 UTC (permalink / raw)
To: David Miller
Cc: segoon, mjt, linux-kernel, arnd, mirqus, netdev, bhutchings,
kuznet, pekkas, yoshfuji, kaber, eric.dumazet, therbert, xiaosuo,
jesse, kees.cook, eugene, dan.j.rosenberg
In-Reply-To: <20110309.140928.70185544.davem@davemloft.net>
On Wed, 9 Mar 2011, David Miller wrote:
> I was hoping someone other than me would take this upstream, feel free
> to submit it directly to Linus with my ack:
>
> Acked-by: David S. Miller <davem@davemloft.net>
I can submit it via my tree.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: Network performance with small packets - continued
From: Tom Lendacky @ 2011-03-09 22:51 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shirley Ma, Rusty Russell, Krishna Kumar2, David Miller, kvm,
netdev, steved
In-Reply-To: <201103091009.27932.tahm@linux.vnet.ibm.com>
On Wednesday, March 09, 2011 10:09:26 am Tom Lendacky wrote:
> On Wednesday, March 09, 2011 01:15:58 am Michael S. Tsirkin wrote:
> > On Mon, Mar 07, 2011 at 04:31:41PM -0600, Tom Lendacky wrote:
> > > We've been doing some more experimenting with the small packet network
> > > performance problem in KVM. I have a different setup than what Steve
> > > D. was using so I re-baselined things on the kvm.git kernel on both
> > > the host and guest with a 10GbE adapter. I also made use of the
> > > virtio-stats patch.
> > >
> > > The virtual machine has 2 vCPUs, 8GB of memory and two virtio network
> > > adapters (the first connected to a 1GbE adapter and a LAN, the second
> > > connected to a 10GbE adapter that is direct connected to another system
> > > with the same 10GbE adapter) running the kvm.git kernel. The test was
> > > a TCP_RR test with 100 connections from a baremetal client to the KVM
> > > guest using a 256 byte message size in both directions.
> > >
> > > I used the uperf tool to do this after verifying the results against
> > > netperf. Uperf allows the specification of the number of connections as
> > > a parameter in an XML file as opposed to launching, in this case, 100
> > > separate instances of netperf.
> > >
> > > Here is the baseline for baremetal using 2 physical CPUs:
> > > Txn Rate: 206,389.59 Txn/Sec, Pkt Rate: 410,048 Pkts/Sec
> > > TxCPU: 7.88% RxCPU: 99.41%
> > >
> > > To be sure to get consistent results with KVM I disabled the
> > > hyperthreads, pinned the qemu-kvm process, vCPUs, vhost thread and
> > > ethernet adapter interrupts (this resulted in runs that differed by
> > > only about 2% from lowest to highest). The fact that pinning is
> > > required to get consistent results is a different problem that we'll
> > > have to look into later...
> > >
> > > Here is the KVM baseline (average of six runs):
> > > Txn Rate: 87,070.34 Txn/Sec, Pkt Rate: 172,992 Pkts/Sec
> > > Exits: 148,444.58 Exits/Sec
> > > TxCPU: 2.40% RxCPU: 99.35%
> > >
> > > About 42% of baremetal.
> >
> > Can you add interrupt stats as well please?
>
> Yes I can. Just the guest interrupts for the virtio device?
>
> > > empty. So I coded a quick patch to delay freeing of the used Tx
> > > buffers until more than half the ring was used (I did not test this
> > > under a stream condition so I don't know if this would have a negative
> > > impact). Here are the results
> > >
> > > from delaying the freeing of used Tx buffers (average of six runs):
> > > Txn Rate: 90,886.19 Txn/Sec, Pkt Rate: 180,571 Pkts/Sec
> > > Exits: 142,681.67 Exits/Sec
> > > TxCPU: 2.78% RxCPU: 99.36%
> > >
> > > About a 4% increase over baseline and about 44% of baremetal.
> >
> > Hmm, I am not sure what you mean by delaying freeing.
>
> In the start_xmit function of virtio_net.c the first thing done is to free
> any used entries from the ring. I patched the code to track the number of
> used tx ring entries and only free the used entries when they are greater
> than half the capacity of the ring (similar to the way the rx ring is
> re-filled).
>
> > I think we do have a problem that free_old_xmit_skbs
> > tries to flush out the ring aggressively:
> > it always polls until the ring is empty,
> > so there could be bursts of activity where
> > we spend a lot of time flushing the old entries
> > before e.g. sending an ack, resulting in
> > latency bursts.
> >
> > Generally we'll need some smarter logic,
> > but with indirect at the moment we can just poll
> > a single packet after we post a new one, and be done with it.
> > Is your patch something like the patch below?
> > Could you try mine as well please?
>
> Yes, I'll try the patch and post the results.
>
> > > This spread out the kick_notify but still resulted in alot of them. I
> > > decided to build on the delayed Tx buffer freeing and code up an
> > > "ethtool" like coalescing patch in order to delay the kick_notify until
> > > there were at least 5 packets on the ring or 2000 usecs, whichever
> > > occurred first. Here are the
> > >
> > > results of delaying the kick_notify (average of six runs):
> > > Txn Rate: 107,106.36 Txn/Sec, Pkt Rate: 212,796 Pkts/Sec
> > > Exits: 102,587.28 Exits/Sec
> > > TxCPU: 3.03% RxCPU: 99.33%
> > >
> > > About a 23% increase over baseline and about 52% of baremetal.
> > >
> > > Running the perf command against the guest I noticed almost 19% of the
> > > time being spent in _raw_spin_lock. Enabling lockstat in the guest
> > > showed alot of contention in the "irq_desc_lock_class". Pinning the
> > > virtio1-input interrupt to a single cpu in the guest and re-running the
> > > last test resulted in
> > >
> > > tremendous gains (average of six runs):
> > > Txn Rate: 153,696.59 Txn/Sec, Pkt Rate: 305,358 Pkgs/Sec
> > > Exits: 62,603.37 Exits/Sec
> > > TxCPU: 3.73% RxCPU: 98.52%
> > >
> > > About a 77% increase over baseline and about 74% of baremetal.
> > >
> > > Vhost is receiving a lot of notifications for packets that are to be
> > > transmitted (over 60% of the packets generate a kick_notify). Also, it
> > > looks like vhost is sending a lot of notifications for packets it has
> > > received before the guest can get scheduled to disable notifications
> > > and begin processing the packets
> >
> > Hmm, is this really what happens to you? The effect would be that guest
> > gets an interrupt while notifications are disabled in guest, right? Could
> > you add a counter and check this please?
>
> The disabling of the interrupt/notifications is done by the guest. So the
> guest has to get scheduled and handle the notification before it disables
> them. The vhost_signal routine will keep injecting an interrupt until this
> happens causing the contention in the guest. I'll try the patches you
> specify below and post the results. They look like they should take care
> of this issue.
>
> > Another possible thing to try would be these old patches to publish used
> >
> > index from guest to make sure this double interrupt does not happen:
> > [PATCHv2] virtio: put last seen used index into ring itself
> > [PATCHv2] vhost-net: utilize PUBLISH_USED_IDX feature
I was able to apply these patches with a little work, but unfortunately the
guest oops during boot up in virtqueue_add_buf_gfp. It happens in the
virtio_blk driver. Any chance you can re-work these patches against the
kvm.git tree?
> >
> > > resulting in some lock contention in the guest (and
> > > high interrupt rates).
> > >
> > > Some thoughts for the transmit path... can vhost be enhanced to do
> > > some adaptive polling so that the number of kick_notify events are
> > > reduced and replaced by kick_no_notify events?
> >
> > Worth a try.
> >
> > > Comparing the transmit path to the receive path, the guest disables
> > > notifications after the first kick and vhost re-enables notifications
> > > after completing processing of the tx ring.
> >
> > Is this really what happens? I though the host disables notifications
> > after the first kick.
>
> Yup, sorry for the confusion. The kick is done by the guest and then vhost
> disables notifications. Maybe a similar approach to the above patches of
> checking the used index in the virtio_net driver could also help here?
>
> > > Can a similar thing be done for the
> > >
> > > receive path? Once vhost sends the first notification for a received
> > > packet it can disable notifications and let the guest re-enable
> > > notifications when it has finished processing the receive ring. Also,
> > > can the virtio-net driver do some adaptive polling (or does napi take
> > > care of that for the guest)?
> >
> > Worth a try. I don't think napi does anything like this.
> >
> > > Running the same workload on the same configuration with a different
> > > hypervisor results in performance that is almost equivalent to
> > > baremetal without doing any pinning.
> > >
> > > Thanks,
> > > Tom Lendacky
> >
> > There's no need to flush out all used buffers
> > before we post more for transmit: with indirect,
> > just a single one is enough. Without indirect we'll
> > need more possibly, but just for testing this should
> > be enough.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > ---
> >
> > Note: untested.
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 82dba5a..ebe3337 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -514,11 +514,11 @@ static unsigned int free_old_xmit_skbs(struct
> > virtnet_info *vi) struct sk_buff *skb;
> >
> > unsigned int len, tot_sgs = 0;
> >
> > - while ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
> > + if ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
> >
> > pr_debug("Sent skb %p\n", skb);
> > vi->dev->stats.tx_bytes += skb->len;
> > vi->dev->stats.tx_packets++;
> >
> > - tot_sgs += skb_vnet_hdr(skb)->num_sg;
> > + tot_sgs = 2+MAX_SKB_FRAGS;
> >
> > dev_kfree_skb_any(skb);
> >
> > }
> > return tot_sgs;
> >
> > @@ -576,9 +576,6 @@ static netdev_tx_t start_xmit(struct sk_buff *skb,
> > struct net_device *dev) struct virtnet_info *vi = netdev_priv(dev);
> >
> > int capacity;
> >
> > - /* Free up any pending old buffers before queueing new ones. */
> > - free_old_xmit_skbs(vi);
> > -
> >
> > /* Try to transmit */
> > capacity = xmit_skb(vi, skb);
> >
> > @@ -605,6 +602,10 @@ static netdev_tx_t start_xmit(struct sk_buff *skb,
> > struct net_device *dev) skb_orphan(skb);
> >
> > nf_reset(skb);
> >
> > + /* Free up any old buffers so we can queue new ones. */
> > + if (capacity < 2+MAX_SKB_FRAGS)
> > + capacity += free_old_xmit_skbs(vi);
> > +
> >
> > /* Apparently nice girls don't return TX_BUSY; stop the queue
> >
> > * before it gets out of hand. Naturally, this wastes entries. */
> >
> > if (capacity < 2+MAX_SKB_FRAGS) {
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" 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: Network performance with small packets - continued
From: Shirley Ma @ 2011-03-09 22:45 UTC (permalink / raw)
To: Tom Lendacky
Cc: Michael S. Tsirkin, Rusty Russell, Krishna Kumar2, David Miller,
kvm, netdev, steved
In-Reply-To: <201103091411.09062.tahm@linux.vnet.ibm.com>
Hello Tom,
Do you also have Rusty's virtio stat patch results for both send queue
and recv queue to share here?
Thanks
Shirley
^ permalink raw reply
* Re: [patch net-next-2.6] net: reinject arps into bonding slave instead of master
From: Nicolas de Pesloüan @ 2011-03-09 22:18 UTC (permalink / raw)
To: Jiri Pirko
Cc: Andy Gospodarek, netdev, davem, shemminger, kaber, fubar,
eric.dumazet
In-Reply-To: <20110309171100.GA2842@psychotron.redhat.com>
Le 09/03/2011 18:11, Jiri Pirko a écrit :
> Wed, Mar 09, 2011 at 04:28:34PM CET, nicolas.2p.debian@gmail.com wrote:
>> Le 09/03/2011 16:09, Jiri Pirko a écrit :
>>> Wed, Mar 09, 2011 at 03:49:49PM CET, nicolas.2p.debian@gmail.com wrote:
>>>> Le 09/03/2011 08:45, Jiri Pirko a écrit :
>>>>> Tue, Mar 08, 2011 at 10:44:37PM CET, nicolas.2p.debian@gmail.com wrote:
>>>>>> Le 08/03/2011 14:42, Andy Gospodarek a écrit :
>>>>>>> I'm pretty sure this patch will have the same catastrophic problem your
>>>>>>> last one did. By cloning and setting skb2->dev = orig_dev you just
>>>>>>> inserted a frame identical to the one we received right back into the
>>>>>>> stack. It only took a few minutes for my box to melt as one frame on
>>>>>>> the wire will cause an infinite number of frames to be received by the
>>>>>>> stack.
>>>>>>
>>>>>> I agree with Andy. We still keep one reinject (netif_rx), which is
>>>>>> probably better that two (__netif_receive_skb), but not enough.
>>>>>>
>>>>>> I really think we need a general framework for late delivery of final
>>>>>> packets to packet handler registered somewhere in the rx_handler
>>>>>> path.
>>>>>>
>>>>>> Jiri, is this patch the one you announced as "I have some kind nice
>>>>>> solution in mind and I'm going to submit that as a patch later (too
>>>>>> many patches are in the wind atm)" ?
>>>>>
>>>>>
>>>>> I did not had time to verify my thought yet but I think that the only
>>>>> think needed against my original patch (bonding: move processing of recv
>>>>> handlers into handle_frame()) is ro remove vlan_on_bond_hook, period.
>>>>>
>>>>> Because all incoming arps are seen by bond_handle_frame =>
>>>>> bond->recv_probe , even vlan ones - that would make eth0-bond0-bond0.5
>>>>> work and eth0-bond0-br0-bond0.5 as well. But again, need to verify this.
>>>>
>>>> All incoming ARPs are seen by bond_handle_frame, even vlan ones, definitely true.
>>>>
>>>> But as some of them *are* vlan ones, you will have to untag those "by hand" inside bond_handle_frame.
>>>
>>
>>> Hmm. For hw vlan accel this would not be needed.
>>
>> Agreed.
>>
>>> But for non-hw-vlan-accel the frame is wrapped when going thru handle_frame. And yes, in that
>>> case untagging would be necessary. Unless the vlan untagging happening now in ptype_base handler
>>> is moved in rx path somewhere before __netif_receive_skb.
>>
>> Can't it me moved not before, but inside __netif_receive_skb, as a rx_handler?
>
> I don't think so - rx_handler is not right place to untag. rx_handler is
> per device. untaging should happen idealy on realdev skb injection. That
> way the rx path for hw-vlan-accel and non-he-vlan-accel would be very
> similar.
I don't understand your argument about "rx_handler is per device". A vlan interface is by design
built on top a parent (physical or logical) interface. Why can't we use the rx_handler of the parent
device to untag?
Untagging the frame very early (before __netif_receive_skb() would work if the value of skb->dev, at
the time the frame enter __netif_receive_skb, is the parent interface for the vlan interface: eth0
-> eth0.100. This is exactly what happens for hw-accel vlan frame and it sounds logical at first to
do it the same way for non-hw-accel device.
But for all others setups, where there exist some net_devices before the "untagging" one, you would
face some troubles. For example, with eth0+eth1 -> br0 -> br0.100, you cannot untag before entering
__netif_receive_skb. If you do so, the bridge would receive untagged frame and if the frame is not
for the local host, the bridge would forward an untagged frame while it is expected to forward a
tagged one. Even if the bridge is in a position to know the frame *was* tagged, we cannot expect the
bridge to do special processing to handle this situation. Doing so would break layering.
On another setup, eth0 -> eth0.100 -> br0 -> eth1.200 -> eth1, on the opposite, we expect the bridge
to receive and to forward an untagged frame, that has been untagged while crossing eth0.100 and will
be tagged while crossing eth1.200.
If we want to avoid reinjection as much as possible (and I advocate for that, you know :-)), then
the only place to untag is in the rx_header for the parent device of the vlan device. I still don't
understand the problem you see with this proposal.
And the only remaining discrepancy would be in hw-accel vs non-hw-accel. A protocol handler
registered on eth0 -> eth0.100 would receive:
- a tagged frame for non-hw-accel.
- an untagged frame for hw-accel.
I think it is already true today, so I don't consider this a problem. We might arrange to fix this
discrepancy later, if someone consider this a problem.
Nicolas.
>> At the time we setup eth0.100, we can arrange for a vlan_untag
>> rx_handler to be registered on eth0. This is exactly the way it works
>> now for macvlan. Should it be possible (and desirable) for vlan too?
>>
>> This might re-open the discussion about the need for several
>> rx_handlers per interface, but that is another story.
>>
>> Also, moving it before __netif_receive_skb would cause every protocol
>> handlers to receive the frame untagged. At least protocol sniffers
>> registered at ptype_all may want to receive the tagged frame, for
>> diagnostic purpose.
>
> Thats how its done for hw-vlan-accel. No problem here.
>
>>
>> That would result in two things:
>>>
>>> 1) Bond would be able to scope vlan packets
>>> 2) The rx path for hw-vlan-accel and non-hw-vlan-accel would be the same
>>> (should be desirable + one reinjection would be avoided for
>>> non-hw-vlan-accel)
>>
>> Agreed, but moving it inside __netif_receive_skb should have the same
>> effects. If we move non-hw-accel-vlan to a rx_handler, the skb would
>> be COW before being untagged only if shared. This sounds good to me.
>>
>> Nicolas.
>
^ permalink raw reply
* Re: [PATCH] pktgen: fix errata in show results
From: David Miller @ 2011-03-09 22:11 UTC (permalink / raw)
To: daniel.turull; +Cc: netdev, ljw, robert
In-Reply-To: <4D74A908.7040302@gmail.com>
From: Daniel Turull <daniel.turull@gmail.com>
Date: Mon, 07 Mar 2011 10:44:40 +0100
> The units in show_results in pktgen were not correct.
> The results are in usec but it was displayed nsec.
>
> Reported-by: Jong-won Lee <ljw@handong.edu>
> Signed-off-by: Daniel Turull <daniel.turull@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] tcp: ioctl type SIOCOUTQNSD returns amount of data not sent
From: David Miller @ 2011-03-09 22:09 UTC (permalink / raw)
To: sledz
Cc: netdev, linux-kernel, alan, kuznet, pekkas, jmorris, yoshfuji,
kaber, m.schuknecht
In-Reply-To: <1299441595-18455-1-git-send-email-sledz@dresearch.de>
From: Steffen Sledz <sledz@dresearch.de>
Date: Sun, 6 Mar 2011 20:59:55 +0100
> From: Mario Schuknecht <m.schuknecht@dresearch.de>
>
> In contrast to SIOCOUTQ which returns the amount of data sent
> but not yet acknowledged plus data not yet sent this patch only
> returns the data not sent.
>
> For various methods of live streaming bitrate control it may
> be helpful to know how much data are in the tcp outqueue are
> not sent yet.
>
> Signed-off-by: Mario Schuknecht <m.schuknecht@dresearch.de>
> Signed-off-by: Steffen Sledz <sledz@dresearch.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: David Miller @ 2011-03-09 22:09 UTC (permalink / raw)
To: segoon
Cc: mjt, linux-kernel, arnd, mirqus, netdev, bhutchings, kuznet,
pekkas, jmorris, yoshfuji, kaber, eric.dumazet, therbert, xiaosuo,
jesse, kees.cook, eugene, dan.j.rosenberg
In-Reply-To: <20110309220633.GA14750@albatros>
From: Vasiliy Kulikov <segoon@openwall.com>
Date: Thu, 10 Mar 2011 01:06:34 +0300
> On Wed, Mar 02, 2011 at 10:15 +0300, Michael Tokarev wrote:
>> 02.03.2011 00:33, Vasiliy Kulikov wrote:
>> > Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with
>> > CAP_NET_ADMIN may load any module from /lib/modules/. This doesn't mean
>> > that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are
>> > limited to /lib/modules/**. However, CAP_NET_ADMIN capability shouldn't
>> > allow anybody load any module not related to networking.
>> >
>> > This patch restricts an ability of autoloading modules to netdev modules
>> > with explicit aliases. This fixes CVE-2011-1019.
>> []
>> > Reference: https://lkml.org/lkml/2011/2/24/203
>> >
>> > Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
>>
>> This looks much saner :)
>>
>> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
>
> Is there any reason why it is not yet merged? I've answered to Jake
> Edge that it is not a regression.
I was hoping someone other than me would take this upstream, feel free
to submit it directly to Linus with my ack:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Vasiliy Kulikov @ 2011-03-09 22:06 UTC (permalink / raw)
To: Michael Tokarev
Cc: linux-kernel, arnd, mirqus, netdev, Ben Hutchings, David Miller,
kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet, therbert,
xiaosuo, jesse, kees.cook, eugene, dan.j.rosenberg
In-Reply-To: <4D6DEE7C.6020700@msgid.tls.msk.ru>
On Wed, Mar 02, 2011 at 10:15 +0300, Michael Tokarev wrote:
> 02.03.2011 00:33, Vasiliy Kulikov wrote:
> > Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with
> > CAP_NET_ADMIN may load any module from /lib/modules/. This doesn't mean
> > that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are
> > limited to /lib/modules/**. However, CAP_NET_ADMIN capability shouldn't
> > allow anybody load any module not related to networking.
> >
> > This patch restricts an ability of autoloading modules to netdev modules
> > with explicit aliases. This fixes CVE-2011-1019.
> []
> > Reference: https://lkml.org/lkml/2011/2/24/203
> >
> > Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
>
> This looks much saner :)
>
> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Is there any reason why it is not yet merged? I've answered to Jake
Edge that it is not a regression.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: [PATCH] ipv4: Remove flowi from struct rtable.
From: David Miller @ 2011-03-09 22:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20110304.230914.112605809.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 04 Mar 2011 23:09:14 -0800 (PST)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sat, 05 Mar 2011 07:59:48 +0100
>
>> Eventually we could have a helper for this, as this is done three times
>> in this file. Or maybe you have further plans for ipmr ?
>
> No immediate plans, so yes I'll make a helper, good idea.
Sorry for taking so long on this, I just added the following to net-next-2.6:
--------------------
ipv4: Lookup multicast routes by rtable using helper.
Create a common helper for this operation, since we do
it identically in three spots.
Suggested by Eric Dumazet.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/ipmr.c | 70 ++++++++++++++++++++++---------------------------------
1 files changed, 28 insertions(+), 42 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 9d5f634..74909ba 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1793,6 +1793,24 @@ dont_forward:
return 0;
}
+static struct mr_table *ipmr_rt_fib_lookup(struct net *net, struct rtable *rt)
+{
+ struct flowi fl = {
+ .fl4_dst = rt->rt_key_dst,
+ .fl4_src = rt->rt_key_src,
+ .fl4_tos = rt->rt_tos,
+ .oif = rt->rt_oif,
+ .iif = rt->rt_iif,
+ .mark = rt->rt_mark,
+ };
+ struct mr_table *mrt;
+ int err;
+
+ err = ipmr_fib_lookup(net, &fl, &mrt);
+ if (err)
+ return ERR_PTR(err);
+ return mrt;
+}
/*
* Multicast packets for forwarding arrive here
@@ -1805,7 +1823,6 @@ int ip_mr_input(struct sk_buff *skb)
struct net *net = dev_net(skb->dev);
int local = skb_rtable(skb)->rt_flags & RTCF_LOCAL;
struct mr_table *mrt;
- int err;
/* Packet is looped back after forward, it should not be
* forwarded second time, but still can be delivered locally.
@@ -1813,21 +1830,10 @@ int ip_mr_input(struct sk_buff *skb)
if (IPCB(skb)->flags & IPSKB_FORWARDED)
goto dont_forward;
- {
- struct rtable *rt = skb_rtable(skb);
- struct flowi fl = {
- .fl4_dst = rt->rt_key_dst,
- .fl4_src = rt->rt_key_src,
- .fl4_tos = rt->rt_tos,
- .oif = rt->rt_oif,
- .iif = rt->rt_iif,
- .mark = rt->rt_mark,
- };
- err = ipmr_fib_lookup(net, &fl, &mrt);
- if (err < 0) {
- kfree_skb(skb);
- return err;
- }
+ mrt = ipmr_rt_fib_lookup(net, skb_rtable(skb));
+ if (IS_ERR(mrt)) {
+ kfree_skb(skb);
+ return PTR_ERR(mrt);
}
if (!local) {
if (IPCB(skb)->opt.router_alert) {
@@ -1956,19 +1962,9 @@ int pim_rcv_v1(struct sk_buff *skb)
pim = igmp_hdr(skb);
- {
- struct rtable *rt = skb_rtable(skb);
- struct flowi fl = {
- .fl4_dst = rt->rt_key_dst,
- .fl4_src = rt->rt_key_src,
- .fl4_tos = rt->rt_tos,
- .oif = rt->rt_oif,
- .iif = rt->rt_iif,
- .mark = rt->rt_mark,
- };
- if (ipmr_fib_lookup(net, &fl, &mrt) < 0)
- goto drop;
- }
+ mrt = ipmr_rt_fib_lookup(net, skb_rtable(skb));
+ if (IS_ERR(mrt))
+ goto drop;
if (!mrt->mroute_do_pim ||
pim->group != PIM_V1_VERSION || pim->code != PIM_V1_REGISTER)
goto drop;
@@ -1998,19 +1994,9 @@ static int pim_rcv(struct sk_buff *skb)
csum_fold(skb_checksum(skb, 0, skb->len, 0))))
goto drop;
- {
- struct rtable *rt = skb_rtable(skb);
- struct flowi fl = {
- .fl4_dst = rt->rt_key_dst,
- .fl4_src = rt->rt_key_src,
- .fl4_tos = rt->rt_tos,
- .oif = rt->rt_oif,
- .iif = rt->rt_iif,
- .mark = rt->rt_mark,
- };
- if (ipmr_fib_lookup(net, &fl, &mrt) < 0)
- goto drop;
- }
+ mrt = ipmr_rt_fib_lookup(net, skb_rtable(skb));
+ if (IS_ERR(mrt))
+ goto drop;
if (__pim_rcv(mrt, skb, sizeof(*pim))) {
drop:
kfree_skb(skb);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] Fix variable assignment in ip_vs_notrack
From: Simon Horman @ 2011-03-09 22:05 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-kernel, lvs-devel, netdev, Wensong Zhang, trivial
In-Reply-To: <alpine.LNX.2.00.1103092250510.4471@swampdragon.chaosbits.net>
On Wed, Mar 09, 2011 at 10:55:05PM +0100, Jesper Juhl wrote:
> There's no sense to 'ct = ct = ' in ip_vs_notrack(). Just assign
> nf_ct_get()'s return value directly to the pointer variable 'ct' once.
Thanks Jesper, applied to lvs-test-2.6.
^ permalink raw reply
* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Lucas Nussbaum @ 2011-03-09 22:03 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Yuchung Cheng, Injong Rhee, David Miller, xiyou.wangcong, netdev,
sangtae.ha
In-Reply-To: <20110309135122.1bafe500@nehalam>
On 09/03/11 at 13:51 -0800, Stephen Hemminger wrote:
> On Wed, 9 Mar 2011 22:33:56 +0100
> Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
>
> > On 09/03/11 at 13:12 -0800, Yuchung Cheng wrote:
> > > On Wed, Mar 9, 2011 at 12:01 PM, Stephen Hemminger
> > > <shemminger@vyatta.com> wrote:
> > > > On Wed, 9 Mar 2011 19:25:05 +0100
> > > > Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> > > >
> > > >> On 09/03/11 at 09:56 -0800, Stephen Hemminger wrote:
> > > >> > On Wed, 9 Mar 2011 07:53:19 +0100
> > > >> > Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> > > >> >
> > > >> > > On 08/03/11 at 20:30 -0500, Injong Rhee wrote:
> > > >> > > > Now, both tools can be wrong. But that is not catastrophic since
> > > >> > > > congestion avoidance can kick in to save the day. In a pipe where no
> > > >> > > > other flows are competing, then exiting slow start too early can
> > > >> > > > slow things down as the window can be still too small. But that is
> > > >> > > > in fact when delays are most reliable. So those tests that say bad
> > > >> > > > performance with hystart are in fact, where hystart is supposed to
> > > >> > > > perform well.
> > > >> > >
> > > >> > > Hi,
> > > >> > >
> > > >> > > In my setup, there is no congestion at all (except the buffer bloat).
> > > >> > > Without Hystart, transferring 8 Gb of data takes 9s, with CUBIC exiting
> > > >> > > slow start at ~2000 packets.
> > > >> > > With Hystart, transferring 8 Gb of data takes 19s, with CUBIC exiting
> > > >> > > slow start at ~20 packets.
> > > >> > > I don't think that this is "hystart performing well". We could just as
> > > >> > > well remove slow start completely, and only do congestion avoidance,
> > > >> > > then.
> > > >> > >
> > > >> > > While I see the value in Hystart, it's clear that there are some flaws
> > > >> > > in the current implementation. It probably makes sense to disable
> > > >> > > hystart by default until those problems are fixed.
> > > >> >
> > > >> > What is the speed and RTT time of your network?
> > > >> > I think you maybe blaming hystart for other issues in the network.
> > > >>
> > > >> What kind of issues?
> > > >>
> > > >> Host1 is connected through a gigabit ethernet LAN to Router1
> > > >> Host2 is connected through a gigabit ethernet LAN to Router2
> > > >> Router1 and Router2 are connected through an experimentation network at
> > > >> 10 Gb/s
> > > >> RTT between Host1 and Host2 is 11.3ms.
> > > >> The network is not congested.
> > > >
> > > > By my calculations (1G * 11.3ms) gives BDP of 941 packets which means
> > > > CUBIC would ideally exit slow start at 900 or so packets. Old CUBIC
> > > > slowstrart of 2000 packets means there is huge overshoot which means
> > > > large packet loss burst which would cause a large CPU load on receiver
> > > > processing SACK.
> > > It's not clear from Lucas's report that the hystart is exiting when
> > > cwnd=2000 or when sender has sent 2000 packets.
> > > Lucas could you clarify?
> >
> > When cwnd is around 2000.
>
> What is HZ on the kernel configuration. Part of the problem is the hystart
> code was only tested with HZ=1000 and there are some bad assumptions there.
$ grep HZ /boot/config-2.6.32-5-amd64
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* Re: Network performance with small packets - continued
From: Michael S. Tsirkin @ 2011-03-09 21:56 UTC (permalink / raw)
To: Tom Lendacky
Cc: Shirley Ma, Rusty Russell, Krishna Kumar2, David Miller, kvm,
netdev, steved
In-Reply-To: <201103091411.09062.tahm@linux.vnet.ibm.com>
On Wed, Mar 09, 2011 at 02:11:07PM -0600, Tom Lendacky wrote:
> Here are the results again with the addition of the interrupt rate that
> occurred on the guest virtio_net device:
>
> Here is the KVM baseline (average of six runs):
> Txn Rate: 87,070.34 Txn/Sec, Pkt Rate: 172,992 Pkts/Sec
> Exits: 148,444.58 Exits/Sec
> TxCPU: 2.40% RxCPU: 99.35%
> Virtio1-input Interrupts/Sec (CPU0/CPU1): 5,154/5,222
> Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
>
> About 42% of baremetal.
>
> Delayed freeing of TX buffers (average of six runs):
> Txn Rate: 90,886.19 Txn/Sec, Pkt Rate: 180,571 Pkts/Sec
> Exits: 142,681.67 Exits/Sec
> TxCPU: 2.78% RxCPU: 99.36%
> Virtio1-input Interrupts/Sec (CPU0/CPU1): 4,796/4,908
> Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
>
> About a 4% increase over baseline and about 44% of baremetal.
Looks like delayed freeing is a good idea generally.
Is this my patch? Yours?
> Delaying kick_notify (kick every 5 packets -average of six runs):
> Txn Rate: 107,106.36 Txn/Sec, Pkt Rate: 212,796 Pkts/Sec
> Exits: 102,587.28 Exits/Sec
> TxCPU: 3.03% RxCPU: 99.33%
> Virtio1-input Interrupts/Sec (CPU0/CPU1): 4,200/4,293
> Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
>
> About a 23% increase over baseline and about 52% of baremetal.
>
> Delaying kick_notify and pinning virtio1-input to CPU0 (average of six runs):
What exactly moves the interrupt handler between CPUs?
irqbalancer? Does it matter which CPU you pin it to?
If yes, do you have any idea why?
Also, what happens without delaying kick_notify
but with pinning?
> Txn Rate: 153,696.59 Txn/Sec, Pkt Rate: 305,358 Pkgs/Sec
> Exits: 62,603.37 Exits/Sec
> TxCPU: 3.73% RxCPU: 98.52%
> Virtio1-input Interrupts/Sec (CPU0/CPU1): 11,564/0
> Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
>
> About a 77% increase over baseline and about 74% of baremetal.
Hmm we get about 20 packets per interrupt on average.
That's pretty decent. The problem is with exits.
Let's try something adaptive in the host?
--
MST
^ permalink raw reply
* [PATCH] Fix variable assignment in ip_vs_notrack
From: Jesper Juhl @ 2011-03-09 21:55 UTC (permalink / raw)
To: linux-kernel; +Cc: lvs-devel, netdev, netdev, Wensong Zhang, trivial
There's no sense to 'ct = ct = ' in ip_vs_notrack(). Just assign
nf_ct_get()'s return value directly to the pointer variable 'ct' once.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
ip_vs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index b7bbd6c..269d1ef 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1031,7 +1031,7 @@ static inline void ip_vs_notrack(struct sk_buff *skb)
{
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
enum ip_conntrack_info ctinfo;
- struct nf_conn *ct = ct = nf_ct_get(skb, &ctinfo);
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
if (!ct || !nf_ct_is_untracked(ct)) {
nf_reset(skb);
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* Re: Stale entries in RT_TABLE_LOCAL
From: David Miller @ 2011-03-09 21:53 UTC (permalink / raw)
To: alexandre.sidorenko; +Cc: netdev, ja
In-Reply-To: <201102231243.23579.alexandre.sidorenko@hp.com>
From: Alex Sidorenko <alexandre.sidorenko@hp.com>
Date: Wed, 23 Feb 2011 12:43:23 -0500
> I am not sure what is the best way to fix this, I can think of several
> approaches:
>
> (a) change the sources so that it would be impossible to add the same IP
> multiple times, even with different masks. I cannot think of any
> situation where adding the same IP (but with different mask) to the same
> interface could be useful. But maybe I am wrong?
I'm leaning towards this solution if it's viable. But I'm not so sure that
nobody uses this feature, maybe Julian knows?
Julian, the issue is that if you add the same IP address multiple times using
different subnet masks, we allow it.
But removal doesn't work correctly, we clear the IFA list on the device but we
leave stale entries in the local routing table.
The test case is:
ip addr add 192.168.142.109/23 dev dummy0
ip addr add 192.168.142.109/22 dev dummy0
ip addr del 192.168.142.109/22 dev dummy0
ip addr del 192.168.142.109/23 dev dummy0
^ permalink raw reply
* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Stephen Hemminger @ 2011-03-09 21:51 UTC (permalink / raw)
To: Lucas Nussbaum
Cc: Yuchung Cheng, Injong Rhee, David Miller, xiyou.wangcong, netdev,
sangtae.ha
In-Reply-To: <20110309213356.GA2898@xanadu.blop.info>
On Wed, 9 Mar 2011 22:33:56 +0100
Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> On 09/03/11 at 13:12 -0800, Yuchung Cheng wrote:
> > On Wed, Mar 9, 2011 at 12:01 PM, Stephen Hemminger
> > <shemminger@vyatta.com> wrote:
> > > On Wed, 9 Mar 2011 19:25:05 +0100
> > > Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> > >
> > >> On 09/03/11 at 09:56 -0800, Stephen Hemminger wrote:
> > >> > On Wed, 9 Mar 2011 07:53:19 +0100
> > >> > Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> > >> >
> > >> > > On 08/03/11 at 20:30 -0500, Injong Rhee wrote:
> > >> > > > Now, both tools can be wrong. But that is not catastrophic since
> > >> > > > congestion avoidance can kick in to save the day. In a pipe where no
> > >> > > > other flows are competing, then exiting slow start too early can
> > >> > > > slow things down as the window can be still too small. But that is
> > >> > > > in fact when delays are most reliable. So those tests that say bad
> > >> > > > performance with hystart are in fact, where hystart is supposed to
> > >> > > > perform well.
> > >> > >
> > >> > > Hi,
> > >> > >
> > >> > > In my setup, there is no congestion at all (except the buffer bloat).
> > >> > > Without Hystart, transferring 8 Gb of data takes 9s, with CUBIC exiting
> > >> > > slow start at ~2000 packets.
> > >> > > With Hystart, transferring 8 Gb of data takes 19s, with CUBIC exiting
> > >> > > slow start at ~20 packets.
> > >> > > I don't think that this is "hystart performing well". We could just as
> > >> > > well remove slow start completely, and only do congestion avoidance,
> > >> > > then.
> > >> > >
> > >> > > While I see the value in Hystart, it's clear that there are some flaws
> > >> > > in the current implementation. It probably makes sense to disable
> > >> > > hystart by default until those problems are fixed.
> > >> >
> > >> > What is the speed and RTT time of your network?
> > >> > I think you maybe blaming hystart for other issues in the network.
> > >>
> > >> What kind of issues?
> > >>
> > >> Host1 is connected through a gigabit ethernet LAN to Router1
> > >> Host2 is connected through a gigabit ethernet LAN to Router2
> > >> Router1 and Router2 are connected through an experimentation network at
> > >> 10 Gb/s
> > >> RTT between Host1 and Host2 is 11.3ms.
> > >> The network is not congested.
> > >
> > > By my calculations (1G * 11.3ms) gives BDP of 941 packets which means
> > > CUBIC would ideally exit slow start at 900 or so packets. Old CUBIC
> > > slowstrart of 2000 packets means there is huge overshoot which means
> > > large packet loss burst which would cause a large CPU load on receiver
> > > processing SACK.
> > It's not clear from Lucas's report that the hystart is exiting when
> > cwnd=2000 or when sender has sent 2000 packets.
> > Lucas could you clarify?
>
> When cwnd is around 2000.
What is HZ on the kernel configuration. Part of the problem is the hystart
code was only tested with HZ=1000 and there are some bad assumptions there.
--
^ permalink raw reply
* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Lucas Nussbaum @ 2011-03-09 21:33 UTC (permalink / raw)
To: Yuchung Cheng
Cc: Stephen Hemminger, Injong Rhee, David Miller, xiyou.wangcong,
netdev, sangtae.ha
In-Reply-To: <AANLkTimpLWoSB2H9PObxwK1iGkFBWQZMw=1kTP9BA7qb@mail.gmail.com>
On 09/03/11 at 13:12 -0800, Yuchung Cheng wrote:
> On Wed, Mar 9, 2011 at 12:01 PM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> > On Wed, 9 Mar 2011 19:25:05 +0100
> > Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> >
> >> On 09/03/11 at 09:56 -0800, Stephen Hemminger wrote:
> >> > On Wed, 9 Mar 2011 07:53:19 +0100
> >> > Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> >> >
> >> > > On 08/03/11 at 20:30 -0500, Injong Rhee wrote:
> >> > > > Now, both tools can be wrong. But that is not catastrophic since
> >> > > > congestion avoidance can kick in to save the day. In a pipe where no
> >> > > > other flows are competing, then exiting slow start too early can
> >> > > > slow things down as the window can be still too small. But that is
> >> > > > in fact when delays are most reliable. So those tests that say bad
> >> > > > performance with hystart are in fact, where hystart is supposed to
> >> > > > perform well.
> >> > >
> >> > > Hi,
> >> > >
> >> > > In my setup, there is no congestion at all (except the buffer bloat).
> >> > > Without Hystart, transferring 8 Gb of data takes 9s, with CUBIC exiting
> >> > > slow start at ~2000 packets.
> >> > > With Hystart, transferring 8 Gb of data takes 19s, with CUBIC exiting
> >> > > slow start at ~20 packets.
> >> > > I don't think that this is "hystart performing well". We could just as
> >> > > well remove slow start completely, and only do congestion avoidance,
> >> > > then.
> >> > >
> >> > > While I see the value in Hystart, it's clear that there are some flaws
> >> > > in the current implementation. It probably makes sense to disable
> >> > > hystart by default until those problems are fixed.
> >> >
> >> > What is the speed and RTT time of your network?
> >> > I think you maybe blaming hystart for other issues in the network.
> >>
> >> What kind of issues?
> >>
> >> Host1 is connected through a gigabit ethernet LAN to Router1
> >> Host2 is connected through a gigabit ethernet LAN to Router2
> >> Router1 and Router2 are connected through an experimentation network at
> >> 10 Gb/s
> >> RTT between Host1 and Host2 is 11.3ms.
> >> The network is not congested.
> >
> > By my calculations (1G * 11.3ms) gives BDP of 941 packets which means
> > CUBIC would ideally exit slow start at 900 or so packets. Old CUBIC
> > slowstrart of 2000 packets means there is huge overshoot which means
> > large packet loss burst which would cause a large CPU load on receiver
> > processing SACK.
> It's not clear from Lucas's report that the hystart is exiting when
> cwnd=2000 or when sender has sent 2000 packets.
> Lucas could you clarify?
When cwnd is around 2000.
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* TX from KVM guest virtio_net to vhost issues
From: Shirley Ma @ 2011-03-09 21:46 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Tom Lendacky, Rusty Russell, Krishna Kumar2, David Miller, kvm,
netdev, steved
Since we have lots of performance discussions about virtio_net and vhost
communication. I think it's better to have a common understandings of
the code first, then we can seek the right directions to improve it. We
also need to collect more statistics data on both virtio and vhost.
Let's look at TX first: from virtio_net(guest) to vhost(host), send vq
is shared between guest virtio_net and host vhost, it uses memory
barriers to sync the changes.
In the start:
Guest virtio_net TX send completion interrupt (for freeing used skbs) is
disable. Guest virtio_net TX send completion interrupt is enabled only
when send vq is overrun, guest needs to wait vhost to consume more
available skbs.
Host vhost notification is enabled in the beginning (for consuming
available skbs); It is disable whenever the send vq is not empty. Once
the send vq is empty, the notification is enabled by vhost.
In guest start_xmit(), it first frees used skbs, then send available
skbs to vhost, ideally guest never enables TX send completion interrupts
to free used skbs if vhost keeps posting used skbs in send vq.
In vhost handle_tx(), it wakes up by guest whenever the send vq has a
skb to send, once the send vq is not empty, vhost exits handle_tx()
without enabling notification. Ideally if guest keeps xmit skbs in send
vq, the notification is never enabled.
I don't see issues on this implementation.
However, in our TCP_STREAM small message size test, we found that
somehow guest couldn't see more used skbs to free, which caused
frequently TX send queue overrun.
In our TCP_RR small message size multiple streams test, we found that
vhost couldn't see more xmit skbs in send vq, thus it enabled
notification too often.
What's the possible cause here in xmit? How guest, vhost are being
scheduled? Whether it's possible, guest virtio_net cooperates with vhost
for ideal performance: both guest virtio_net and vhost can be in pace
with send vq without many notifications and exits?
Thanks
Shirley
^ permalink raw reply
* Re: [PATCH] via-rhine: Work around invalid MAC address error
From: David Miller @ 2011-03-09 21:44 UTC (permalink / raw)
To: mr.nuke.me; +Cc: netdev, rl, florian
In-Reply-To: <4D77F253.5010908@gmail.com>
From: "Alex G." <mr.nuke.me@gmail.com>
Date: Wed, 09 Mar 2011 23:34:11 +0200
> via-rhine drops out of the init code if the hardware provides an invalid
> MAC address. Roger Luethi has had several reports of Rhine NICs doing just
> that. The hardware still works, though; assigning a random MAC address
> allows the NIC to be used as usual. Tested as a standalone interface,
> as carrier for ppp, and as bonding slave.
>
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>
> diff --git a/drivers/net/via-rhine.c.orig b/drivers/net/via-rhine.c
> index 4930f9d..4c1b9e7 100644
> --- a/drivers/net/via-rhine.c.orig
> +++ b/drivers/net/via-rhine.c
This is getting rediculious:
davem@sunset:~/src/GIT/net-2.6$ git apply --check --whitespace=error-all via-rhine-Work-around-invalid-MAC-address-error.patch
error: drivers/net/via-rhine.c.orig: No such file or directory
davem@sunset:~/src/GIT/net-2.6$
davem@sunset:~/src/GIT/net-2.6$ git am --signoff via-rhine-Work-around-invalid-MAC-address-error.patch
Applying: via-rhine: Work around invalid MAC address error
error: drivers/net/via-rhine.c.orig: does not exist in index
Patch failed at 0001 via-rhine: Work around invalid MAC address error
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
You have new mail in /var/mail/davem
davem@sunset:~/src/GIT/net-2.6$ git am --abort
Sorry.
I'm going to ignore you're postings for a day or two, I've already
invested an enormous amount of time and energy into getting you to
submit patches which are properly formed and actually get accepted by
the tools that we all use. Nobody else has these kinds of problems
and can submit properly formed patches.
I would strongly suggest that you try to email the patch to yourself,
save the email into a file, and feed it to "git am" on a fresh tree,
making sure that when then looking at what the resulting commit looks
like.
^ permalink raw reply
* [PATCH] via-rhine: Work around invalid MAC address error
From: Alex G. @ 2011-03-09 21:34 UTC (permalink / raw)
To: netdev; +Cc: Roger Luethi, Florian Fainelli, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: rhine.patch --]
[-- Type: text/x-patch, Size: 1378 bytes --]
via-rhine drops out of the init code if the hardware provides an invalid
MAC address. Roger Luethi has had several reports of Rhine NICs doing just
that. The hardware still works, though; assigning a random MAC address
allows the NIC to be used as usual. Tested as a standalone interface,
as carrier for ppp, and as bonding slave.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
diff --git a/drivers/net/via-rhine.c.orig b/drivers/net/via-rhine.c
index 4930f9d..4c1b9e7 100644
--- a/drivers/net/via-rhine.c.orig
+++ b/drivers/net/via-rhine.c
@@ -762,13 +762,16 @@ static int __devinit rhine_init_one(struct pci_dev *pdev,
for (i = 0; i < 6; i++)
dev->dev_addr[i] = ioread8(ioaddr + StationAddr + i);
- memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
- if (!is_valid_ether_addr(dev->perm_addr)) {
- rc = -EIO;
- printk(KERN_ERR "Invalid MAC address\n");
- goto err_out_unmap;
+ if (!is_valid_ether_addr(dev->dev_addr)) {
+ printk(KERN_ERR "via-rhine: Invalid MAC address: %pM. \n",
+ dev->dev_addr);
+ /* The device may still be used normally if a valid MAC is configured */
+ random_ether_addr(dev->dev_addr);
+ printk(KERN_ERR "via-rhine: Using randomly generated address: %pM instead. \n",
+ dev->dev_addr);
}
+ memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
/* For Rhine-I/II, phy_id is loaded from EEPROM */
if (!phy_id)
^ permalink raw reply related
* Re: [V2 Patch] bonding: move procfs code into bond_procfs.c
From: David Miller @ 2011-03-09 21:34 UTC (permalink / raw)
To: andy; +Cc: amwang, linux-kernel, fubar, netdev
In-Reply-To: <20110307161740.GT11864@gospo.rdu.redhat.com>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Mon, 7 Mar 2011 11:17:40 -0500
> On Mon, Mar 07, 2011 at 03:58:46PM +0800, Amerigo Wang wrote:
>> V2: Move #ifdef CONFIG_PROC_FS into bonding.h, as suggested by David.
>>
>> bond_main.c is bloating, separate the procfs code out,
>> move them to bond_procfs.c
>>
>> Signed-off-by: WANG Cong <amwang@redhat.com>
>>
>
> Looks good and works as expected.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Applied, thanks everyone.
^ 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