* Re: Getting physical packet counts with LRO enabled with ixgbe?
From: Herbert Xu @ 2009-09-25 22:01 UTC (permalink / raw)
To: David Miller; +Cc: greearb, peter.p.waskiewicz.jr, netdev
In-Reply-To: <20090925.145915.68839478.davem@davemloft.net>
On Fri, Sep 25, 2009 at 02:59:15PM -0700, David Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Fri, 25 Sep 2009 14:50:44 -0700
>
> > I get aggregate 18Gbps with LRO v/s 12Gbps without, so it's very
> > much a useful feature for me.
>
> And it'll stay like that until you work with Herbert to fix
> that performance difference.
Actually I believe he's talking about hardware LRO which is a
different beast.
AFAICS the ixgbe driver doesn't use software LRO anymore.
So if it is hardware LRO then what we need is for the hardware
to switch over :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Getting physical packet counts with LRO enabled with ixgbe?
From: David Miller @ 2009-09-25 21:59 UTC (permalink / raw)
To: greearb; +Cc: herbert, peter.p.waskiewicz.jr, netdev
In-Reply-To: <4ABD3B34.8010903@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Fri, 25 Sep 2009 14:50:44 -0700
> I get aggregate 18Gbps with LRO v/s 12Gbps without, so it's very
> much a useful feature for me.
And it'll stay like that until you work with Herbert to fix
that performance difference.
^ permalink raw reply
* Re: Getting physical packet counts with LRO enabled with ixgbe?
From: Peter P Waskiewicz Jr @ 2009-09-25 21:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: greearb@candelatech.com, netdev@vger.kernel.org
In-Reply-To: <20090925214505.GA3472@gondor.apana.org.au>
On Fri, 2009-09-25 at 14:45 -0700, Herbert Xu wrote:
> Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
> >
> >> That's a bummer. I'm guessing you might get close to right on average with some
> >> trivial math, but if someone is sending you pkts with size of 1000 and
> >> your MTU is 1500, would there be any way to tell that the pkts were originally
> >> 1000 bytes instead of 1500?
> >
> > Good point.
>
> Well if you did GRO instead of LRO then none of this would matter :)
ixgbe uses GRO, but we have HW RSC/LRO running on 82599 adapters
underneath GRO.
-PJ
^ permalink raw reply
* Re: Why is LRO off by default on ixgbe?
From: Ben Greear @ 2009-09-25 21:53 UTC (permalink / raw)
To: Herbert Xu; +Cc: shemminger, netdev
In-Reply-To: <20090925214303.GA3399@gondor.apana.org.au>
On 09/25/2009 02:43 PM, Herbert Xu wrote:
> On Fri, Sep 25, 2009 at 02:37:27PM -0700, Herbert Xu wrote:
>>
>>> Ok. It seems GRO was enabled the whole time, but LRO is what gave me the
>>> extra performance boost.
>>>
>>> In this particular case, I'm not actually routing, though I do have ip-forward
>>> enabled, so I guess LRO will be OK as long as I'm careful...
>>
>> What? A driver is either GRO or LRO, it can't be both. What
>> kernel version was this?
>
> Oh perhaps you mean LRO performed by hardware? That would make
> sense indeed. It's also one of the reasons why we hope the hardware
> folks would switch over to GRO so we can enable it for everyone :)
I assume it's in hardware. I am using ixgbe driver, 82599 chipset,
2.6.31 kernel.
GRO was showing as enabled the whole time in ethtool. Turning on LRO gave me an extra
6Gbps (from 12Gbps -> 18Gbps) receive throughput, so it certainly had some affect!
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] 3c59x: Rework suspend and resume
From: Rafael J. Wysocki @ 2009-09-25 21:54 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: David Miller, Alan Stern, linux-pm, netdev
In-Reply-To: <20090925205206.GA9270@oksana.dev.rtsoft.ru>
On Friday 25 September 2009, Anton Vorontsov wrote:
> As noticed by Alan Stern, there is still one issue with the driver:
> we disable PCI IRQ on suspend, but other devices on the same IRQ
> line might still need the IRQ enabled to suspend properly.
>
> Nowadays, PCI core handles all power management work by itself, with
> one condition though: if we use dev_pm_ops. So, rework the driver to
> only quiesce 3c59x internal logic on suspend, while PCI core will
> manage PCI device power state with IRQs disabled.
>
> Suggested-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
> Suggested-by: Alan Stern <stern@rowland.harvard.edu>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/net/3c59x.c | 77 +++++++++++++++++++++++++--------------------------
> 1 files changed, 38 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
> index 7cdd4b0..dee2320 100644
> --- a/drivers/net/3c59x.c
> +++ b/drivers/net/3c59x.c
> @@ -799,52 +799,54 @@ static void poll_vortex(struct net_device *dev)
>
> #ifdef CONFIG_PM
>
> -static int vortex_suspend(struct pci_dev *pdev, pm_message_t state)
> +static int vortex_suspend(struct device *dev)
> {
> - struct net_device *dev = pci_get_drvdata(pdev);
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct net_device *ndev = pci_get_drvdata(pdev);
> +
> + if (!ndev || !netif_running(ndev))
> + return 0;
> +
> + netif_device_detach(ndev);
> + vortex_down(ndev, 1);
>
> - if (dev && netdev_priv(dev)) {
> - if (netif_running(dev)) {
> - netif_device_detach(dev);
> - vortex_down(dev, 1);
> - disable_irq(dev->irq);
> - }
> - pci_save_state(pdev);
> - pci_enable_wake(pdev, pci_choose_state(pdev, state), 0);
> - pci_disable_device(pdev);
> - pci_set_power_state(pdev, pci_choose_state(pdev, state));
> - }
> return 0;
> }
>
> -static int vortex_resume(struct pci_dev *pdev)
> +static int vortex_resume(struct device *dev)
> {
> - struct net_device *dev = pci_get_drvdata(pdev);
> - struct vortex_private *vp = netdev_priv(dev);
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct net_device *ndev = pci_get_drvdata(pdev);
> int err;
>
> - if (dev && vp) {
> - pci_set_power_state(pdev, PCI_D0);
> - pci_restore_state(pdev);
> - err = pci_enable_device(pdev);
> - if (err) {
> - pr_warning("%s: Could not enable device\n",
> - dev->name);
> - return err;
> - }
> - pci_set_master(pdev);
> - if (netif_running(dev)) {
> - err = vortex_up(dev);
> - if (err)
> - return err;
> - enable_irq(dev->irq);
> - netif_device_attach(dev);
> - }
> - }
> + if (!ndev || !netif_running(ndev))
> + return 0;
> +
> + err = vortex_up(ndev);
> + if (err)
> + return err;
> +
> + netif_device_attach(ndev);
> +
> return 0;
> }
>
> -#endif /* CONFIG_PM */
> +static struct dev_pm_ops vortex_pm_ops = {
> + .suspend = vortex_suspend,
> + .resume = vortex_resume,
> + .freeze = vortex_suspend,
> + .thaw = vortex_resume,
> + .poweroff = vortex_suspend,
> + .restore = vortex_resume,
> +};
> +
> +#define VORTEX_PM_OPS (&vortex_pm_ops)
> +
> +#else /* !CONFIG_PM */
> +
> +#define VORTEX_PM_OPS NULL
> +
> +#endif /* !CONFIG_PM */
>
> #ifdef CONFIG_EISA
> static struct eisa_device_id vortex_eisa_ids[] = {
> @@ -3191,10 +3193,7 @@ static struct pci_driver vortex_driver = {
> .probe = vortex_init_one,
> .remove = __devexit_p(vortex_remove_one),
> .id_table = vortex_pci_tbl,
> -#ifdef CONFIG_PM
> - .suspend = vortex_suspend,
> - .resume = vortex_resume,
> -#endif
> + .driver.pm = VORTEX_PM_OPS,
> };
Thanks,
Rafael
^ permalink raw reply
* Re: Getting physical packet counts with LRO enabled with ixgbe?
From: Ben Greear @ 2009-09-25 21:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: Peter P Waskiewicz Jr, netdev
In-Reply-To: <20090925214505.GA3472@gondor.apana.org.au>
On 09/25/2009 02:45 PM, Herbert Xu wrote:
> Peter P Waskiewicz Jr<peter.p.waskiewicz.jr@intel.com> wrote:
>>
>>> That's a bummer. I'm guessing you might get close to right on average with some
>>> trivial math, but if someone is sending you pkts with size of 1000 and
>>> your MTU is 1500, would there be any way to tell that the pkts were originally
>>> 1000 bytes instead of 1500?
>>
>> Good point.
>
> Well if you did GRO instead of LRO then none of this would matter :)
I get aggregate 18Gbps with LRO v/s 12Gbps without, so it's very much a useful feature
for me.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] tunnel: eliminate recursion field
From: Herbert Xu @ 2009-09-25 21:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev
In-Reply-To: <4ABA8254.9000701@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> It seems recursion field from "struct ip_tunnel" is not anymore needed.
> recursion prevention is done at the upper level (in dev_queue_xmit()),
> since we use HARD_TX_LOCK protection for tunnels.
What if we get async processing in between, e.g., nf_queue?
In that case we could end up with a packet that went round and
around until it exceeded the MTU.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Getting physical packet counts with LRO enabled with ixgbe?
From: Herbert Xu @ 2009-09-25 21:45 UTC (permalink / raw)
To: Peter P Waskiewicz Jr; +Cc: greearb, netdev
In-Reply-To: <1253731834.2538.32.camel@localhost.localdomain>
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
>
>> That's a bummer. I'm guessing you might get close to right on average with some
>> trivial math, but if someone is sending you pkts with size of 1000 and
>> your MTU is 1500, would there be any way to tell that the pkts were originally
>> 1000 bytes instead of 1500?
>
> Good point.
Well if you did GRO instead of LRO then none of this would matter :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Why is LRO off by default on ixgbe?
From: Herbert Xu @ 2009-09-25 21:43 UTC (permalink / raw)
To: Ben Greear; +Cc: shemminger, netdev
In-Reply-To: <20090925213727.GA3291@gondor.apana.org.au>
On Fri, Sep 25, 2009 at 02:37:27PM -0700, Herbert Xu wrote:
>
> > Ok. It seems GRO was enabled the whole time, but LRO is what gave me the
> > extra performance boost.
> >
> > In this particular case, I'm not actually routing, though I do have ip-forward
> > enabled, so I guess LRO will be OK as long as I'm careful...
>
> What? A driver is either GRO or LRO, it can't be both. What
> kernel version was this?
Oh perhaps you mean LRO performed by hardware? That would make
sense indeed. It's also one of the reasons why we hope the hardware
folks would switch over to GRO so we can enable it for everyone :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Why is LRO off by default on ixgbe?
From: Herbert Xu @ 2009-09-25 21:37 UTC (permalink / raw)
To: Ben Greear; +Cc: shemminger, netdev
In-Reply-To: <4ABA57D1.5000905@candelatech.com>
Ben Greear <greearb@candelatech.com> wrote:
>
> Ok. It seems GRO was enabled the whole time, but LRO is what gave me the
> extra performance boost.
>
> In this particular case, I'm not actually routing, though I do have ip-forward
> enabled, so I guess LRO will be OK as long as I'm careful...
What? A driver is either GRO or LRO, it can't be both. What
kernel version was this?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH][net-next] LRO: improve aggregation in case of zero TSecr packets
From: Herbert Xu @ 2009-09-25 21:33 UTC (permalink / raw)
To: Octavian Purdila; +Cc: themann, raisch, eric.dumazet, netdev
In-Reply-To: <200908270208.31581.opurdila@ixiacom.com>
Octavian Purdila <opurdila@ixiacom.com> wrote:
>
> This fixes a temporary performance issue we noticed in back to back
> TSO - LRO tests when such tests are run within five minutes after
> boot.
Sorry for responding to old emails again but just for the record,
please keep in mind that LRO is going away so you really should
run your tests with GRO (and update the driver if necessary) as
otherwise your efforts may end up being wasted.
In this particular instance, you're trying to fix an issue that
GRO already fixes.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] [bridge] Fix double-free in br_add_if.
From: Stephen Hemminger @ 2009-09-25 21:33 UTC (permalink / raw)
To: Jeff Hansen; +Cc: netdev, jeff, Dave Miller, Jeff Hansen
In-Reply-To: <1253910324-19006-1-git-send-email-x@jeffhansen.com>
On Fri, 25 Sep 2009 14:25:24 -0600
Jeff Hansen <x@jeffhansen.com> wrote:
> There is a potential double-kfree in net/bridge/br_if.c. If br_fdb_insert
> fails, then the kobject is put back (which calls kfree due to the kobject
> release), and then kfree is called again on the net_bridge_port. This
> patch fixes the crash.
>
> Signed-off-by: Jeff Hansen <x@jeffhansen.com>
> ---
> net/bridge/br_if.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index eb404dc..1becec1 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -368,7 +368,7 @@ done:
> int br_add_if(struct net_bridge *br, struct net_device *dev)
> {
> struct net_bridge_port *p;
> - int err = 0;
> + int err = 0, kobj_initted = 0;
>
> if (dev->flags & IFF_LOOPBACK || dev->type != ARPHRD_ETHER)
> return -EINVAL;
> @@ -391,6 +391,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
> SYSFS_BRIDGE_PORT_ATTR);
> if (err)
> goto err0;
> + kobj_initted = 1;
>
> err = br_fdb_insert(br, p, dev->dev_addr);
> if (err)
> @@ -429,7 +430,8 @@ err0:
> dev_set_promiscuity(dev, -1);
> put_back:
> dev_put(dev);
> - kfree(p);
> + if (!kobj_initted)
> + kfree(p);
> return err;
> }
>
I'll look at it, probably needs fixing, but the code style with condition
variables is out of place in this code.
^ permalink raw reply
* Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
From: Gregory Haskins @ 2009-09-25 21:32 UTC (permalink / raw)
To: Avi Kivity
Cc: Ira W. Snyder, Michael S. Tsirkin, netdev, virtualization, kvm,
linux-kernel, mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze,
alacrityvm-devel
In-Reply-To: <4ABC7DCE.2000404@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 21865 bytes --]
Avi Kivity wrote:
> On 09/24/2009 09:03 PM, Gregory Haskins wrote:
>>
>>> I don't really see how vhost and vbus are different here. vhost expects
>>> signalling to happen through a couple of eventfds and requires someone
>>> to supply them and implement kernel support (if needed). vbus requires
>>> someone to write a connector to provide the signalling implementation.
>>> Neither will work out-of-the-box when implementing virtio-net over
>>> falling dominos, for example.
>>>
>> I realize in retrospect that my choice of words above implies vbus _is_
>> complete, but this is not what I was saying. What I was trying to
>> convey is that vbus is _more_ complete. Yes, in either case some kind
>> of glue needs to be written. The difference is that vbus implements
>> more of the glue generally, and leaves less required to be customized
>> for each iteration.
>>
>
>
> No argument there. Since you care about non-virt scenarios and virtio
> doesn't, naturally vbus is a better fit for them as the code stands.
Thanks for finally starting to acknowledge there's a benefit, at least.
To be more precise, IMO virtio is designed to be a performance oriented
ring-based driver interface that supports all types of hypervisors (e.g.
shmem based kvm, and non-shmem based Xen). vbus is designed to be a
high-performance generic shared-memory interconnect (for rings or
otherwise) framework for environments where linux is the underpinning
"host" (physical or virtual). They are distinctly different, but
complementary (the former addresses the part of the front-end, and
latter addresses the back-end, and a different part of the front-end).
In addition, the kvm-connector used in AlacrityVM's design strives to
add value and improve performance via other mechanisms, such as dynamic
allocation, interrupt coalescing (thus reducing exit-ratio, which is a
serious issue in KVM) and priortizable/nestable signals.
Today there is a large performance disparity between what a KVM guest
sees and what a native linux application sees on that same host. Just
take a look at some of my graphs between "virtio", and "native", for
example:
http://developer.novell.com/wiki/images/b/b7/31-rc4_throughput.png
A dominant vbus design principle is to try to achieve the same IO
performance for all "linux applications" whether they be literally
userspace applications, or things like KVM vcpus or Ira's physical
boards. It also aims to solve problems not previously expressible with
current technologies (even virtio), like nested real-time.
And even though you repeatedly insist otherwise, the neat thing here is
that the two technologies mesh (at least under certain circumstances,
like when virtio is deployed on a shared-memory friendly linux backend
like KVM). I hope that my stack diagram below depicts that clearly.
> But that's not a strong argument for vbus; instead of adding vbus you
> could make virtio more friendly to non-virt
Actually, it _is_ a strong argument then because adding vbus is what
helps makes virtio friendly to non-virt, at least for when performance
matters.
> (there's a limit how far you
> can take this, not imposed by the code, but by virtio's charter as a
> virtual device driver framework).
>
>> Going back to our stack diagrams, you could think of a vhost solution
>> like this:
>>
>> --------------------------
>> | virtio-net
>> --------------------------
>> | virtio-ring
>> --------------------------
>> | virtio-bus
>> --------------------------
>> | ? undefined-1 ?
>> --------------------------
>> | vhost
>> --------------------------
>>
>> and you could think of a vbus solution like this
>>
>> --------------------------
>> | virtio-net
>> --------------------------
>> | virtio-ring
>> --------------------------
>> | virtio-bus
>> --------------------------
>> | bus-interface
>> --------------------------
>> | ? undefined-2 ?
>> --------------------------
>> | bus-model
>> --------------------------
>> | virtio-net-device (vhost ported to vbus model? :)
>> --------------------------
>>
>>
>> So the difference between vhost and vbus in this particular context is
>> that you need to have "undefined-1" do device discovery/hotswap,
>> config-space, address-decode/isolation, signal-path routing, memory-path
>> routing, etc. Today this function is filled by things like virtio-pci,
>> pci-bus, KVM/ioeventfd, and QEMU for x86. I am not as familiar with
>> lguest, but presumably it is filled there by components like
>> virtio-lguest, lguest-bus, lguest.ko, and lguest-launcher. And to use
>> more contemporary examples, we might have virtio-domino, domino-bus,
>> domino.ko, and domino-launcher as well as virtio-ira, ira-bus, ira.ko,
>> and ira-launcher.
>>
>> Contrast this to the vbus stack: The bus-X components (when optionally
>> employed by the connector designer) do device-discovery, hotswap,
>> config-space, address-decode/isolation, signal-path and memory-path
>> routing, etc in a general (and pv-centric) way. The "undefined-2"
>> portion is the "connector", and just needs to convey messages like
>> "DEVCALL" and "SHMSIGNAL". The rest is handled in other parts of the
>> stack.
>>
>>
>
> Right. virtio assumes that it's in a virt scenario and that the guest
> architecture already has enumeration and hotplug mechanisms which it
> would prefer to use. That happens to be the case for kvm/x86.
No, virtio doesn't assume that. It's stack provides the "virtio-bus"
abstraction and what it does assume is that it will be wired up to
something underneath. Kvm/x86 conveniently has pci, so the virtio-pci
adapter was created to reuse much of that facility. For other things
like lguest and s360, something new had to be created underneath to make
up for the lack of pci-like support.
vbus, in conjunction with the kvm-connector, tries to unify that process
a little more by creating a PV-optimized bus. The idea is that it can
be reused in that situation instead of creating a new hypervisor
specific bus each time. It's also designed for high-performance, so you
get that important trait for free simply by tying into it.
>
>> So to answer your question, the difference is that the part that has to
>> be customized in vbus should be a fraction of what needs to be
>> customized with vhost because it defines more of the stack.
>
> But if you want to use the native mechanisms, vbus doesn't have any
> added value.
First of all, thats incorrect. If you want to use the "native"
mechanisms (via the way the vbus-connector is implemented, for instance)
you at least still have the benefit that the backend design is more
broadly re-useable in more environments (like non-virt, for instance),
because vbus does a proper job of defining the requisite
layers/abstractions compared to vhost. So it adds value even in that
situation.
Second of all, with PV there is no such thing as "native". It's
software so it can be whatever we want. Sure, you could argue that the
guest may have built-in support for something like PCI protocol.
However, PCI protocol itself isn't suitable for high-performance PV out
of the can. So you will therefore invariably require new software
layers on top anyway, even if part of the support is already included.
And lastly, why would you _need_ to use the so called "native"
mechanism? The short answer is, "you don't". Any given system (guest
or bare-metal) already have a wide-range of buses (try running "tree
/sys/bus" in Linux). More importantly, the concept of adding new buses
is widely supported in both the Windows and Linux driver model (and
probably any other guest-type that matters). Therefore, despite claims
to the contrary, its not hard or even unusual to add a new bus to the mix.
In summary, vbus is simply one more bus of many, purpose built to
support high-end IO in a virt-like model, giving controlled access to
the linux-host underneath it. You can write a high-performance layer
below the OS bus-model (vbus), or above it (virtio-pci) but either way
you are modifying the stack to add these capabilities, so we might as
well try to get this right.
With all due respect, you are making a big deal out of a minor issue.
>
>> And, as
>> eluded to in my diagram, both virtio-net and vhost (with some
>> modifications to fit into the vbus framework) are potentially
>> complementary, not competitors.
>>
>
> Only theoretically. The existing installed base would have to be thrown
> away
"Thrown away" is pure hyperbole. The installed base, worse case, needs
to load a new driver for a missing device. This is pretty much how
every machine works today, anyway. And if loading a driver was actually
some insurmountable hurdle, as its sometimes implied (but its not in
reality), you can alternatively make vbus look like a legacy bus if you
are willing to sacrifice some of features, like exit-ratio reduction and
priority.
FWIW: AlacrityVM isn't willing to sacrifice those features, so we will
provide a Linux and Windows driver for explicit bus support, as well as
open-specs and community development assistance to any other guest that
wants to add support in the future.
> or we'd need to support both.
>
>
No matter what model we talk about, there's always going to be a "both"
since the userspace virtio models are probably not going to go away (nor
should they).
>
>
>>> Without a vbus-connector-falling-dominos, vbus-venet can't do anything
>>> either.
>>>
>> Mostly covered above...
>>
>> However, I was addressing your assertion that vhost somehow magically
>> accomplishes this "container/addressing" function without any specific
>> kernel support. This is incorrect. I contend that this kernel support
>> is required and present. The difference is that its defined elsewhere
>> (and typically in a transport/arch specific way).
>>
>> IOW: You can basically think of the programmed PIO addresses as forming
>> its "container". Only addresses explicitly added are visible, and
>> everything else is inaccessible. This whole discussion is merely a
>> question of what's been generalized verses what needs to be
>> re-implemented each time.
>>
>
> Sorry, this is too abstract for me.
With all due respect, understanding my point above is required to have
any kind of meaningful discussion here.
>
>
>
>>> vbus doesn't do kvm guest address decoding for the fast path. It's
>>> still done by ioeventfd.
>>>
>> That is not correct. vbus does its own native address decoding in the
>> fast path, such as here:
>>
>> http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=blob;f=kernel/vbus/client.c;h=e85b2d92d629734866496b67455dd307486e394a;hb=e6cbd4d1decca8e829db3b2b9b6ec65330b379e9#l331
>>
>>
>>
>
> All this is after kvm has decoded that vbus is addresses. It can't work
> without someone outside vbus deciding that.
How the connector message is delivered is really not relevant. Some
architectures will simply deliver the message point-to-point (like the
original hypercall design for KVM, or something like Ira's rig), and
some will need additional demuxing (like pci-bridge/pio based KVM).
It's an implementation detail of the connector.
However, the real point here is that something needs to establish a
scoped namespace mechanism, add items to that namespace, and advertise
the presence of the items to the guest. vbus has this facility built in
to its stack. vhost doesn't, so it must come from elsewhere.
>
>> In fact, it's actually a simpler design to unify things this way because
>> you avoid splitting the device model up. Consider how painful the vhost
>> implementation would be if it didn't already have the userspace
>> virtio-net to fall-back on. This is effectively what we face for new
>> devices going forward if that model is to persist.
>>
>
>
> It doesn't have just virtio-net, it has userspace-based hostplug
vbus has hotplug too: mkdir and rmdir
As an added bonus, its device-model is modular. A developer can write a
new device model, compile it, insmod it to the host kernel, hotplug it
to the running guest with mkdir/ln, and the come back out again
(hotunplug with rmdir, rmmod, etc). They may do this all without taking
the guest down, and while eating QEMU based IO solutions for breakfast
performance wise.
Afaict, qemu can't do either of those things.
> and a bunch of other devices impemented in userspace.
Thats fine. I am primarily interested in the high-performance
components, so most of those other items can stay there in userspace if
that is their ideal location.
> Currently qemu has
> virtio bindings for pci and syborg (whatever that is), and device models
> for baloon, block, net, and console, so it seems implementing device
> support in userspace is not as disasterous as you make it to be.
I intentionally qualified "device" with "new" in my statement. And in
that context I was talking about ultimately developing/supporting
in-kernel models, not pure legacy userspace ones. I have no doubt the
implementation of the original userpsace devices was not a difficult or
horrific endeavor.
Requiring new models to be implemented (at least) twice is a poor design
IMO, however. Requiring them to split such a minor portion of their
functionality (like read-only attributes) is a poor design, too. I have
already demonstrated there are other ways to achieve the same
high-performance goals without requiring two models developed/tested
each time and for each manager. For the times I went and tried to
satisfy your request in this manner, developing the code and managing
the resources in two places, for lack of a better description, made me
want to wretch. So I gave up, resolved that my original design was
better, and hoped that I could convince you and the community of the same.
>
>>> Invariably?
>>>
>> As in "always"
>>
>
> Refactor instead of duplicating.
There is no duplicating. vbus has no equivalent today as virtio doesn't
define these layers.
>
>>
>>> Use libraries (virtio-shmem.ko, libvhost.so).
>>>
>> What do you suppose vbus is? vbus-proxy.ko = virtio-shmem.ko, and you
>> dont need libvhost.so per se since you can just use standard kernel
>> interfaces (like configfs/sysfs). I could create an .so going forward
>> for the new ioctl-based interface, I suppose.
>>
>
> Refactor instead of rewriting.
There is no rewriting. vbus has no equivalent today as virtio doesn't
define these layers.
By your own admission, you said if you wanted that capability, use a
library. What I think you are not understanding is vbus _is_ that
library. So what is the problem, exactly?
>
>
>
>>> For kvm/x86 pci definitely remains king.
>>>
>> For full virtualization, sure. I agree. However, we are talking about
>> PV here. For PV, PCI is not a requirement and is a technical dead-end
>> IMO.
>>
>> KVM seems to be the only virt solution that thinks otherwise (*), but I
>> believe that is primarily a condition of its maturity. I aim to help
>> advance things here.
>>
>> (*) citation: xen has xenbus, lguest has lguest-bus, vmware has some
>> vmi-esq thing (I forget what its called) to name a few. Love 'em or
>> hate 'em, most other hypervisors do something along these lines. I'd
>> like to try to create one for KVM, but to unify them all (at least for
>> the Linux-based host designs).
>>
>
> VMware are throwing VMI away (won't be supported in their new product,
> and they've sent a patch to rip it off from Linux);
vmware only cares about x86 iiuc, so probably not a good example.
> Xen has to tunnel
> xenbus in pci for full virtualization (which is where Windows is, and
> where Linux will be too once people realize it's faster). lguest is
> meant as an example hypervisor, not an attempt to take over the world.
So pick any other hypervisor, and the situation is often similar.
>
> "PCI is a dead end" could not be more wrong, it's what guests support.
It's what _some_ guests support. Even for the guests that support it,
it's not well designed for PV. Therefore, you have to do a bunch of
dancing and waste resources on top to squeeze every last drop of
performance out of your platform. In addition, it has a bunch of
baggage that goes with it that is not necessary to do the job in a
software environment. It is therefore burdensome to recreate if you
don't already have something to leverage, like QEMU, just for the sake
of creating the illusion that its there.
Sounds pretty dead to me, sorry. We don't need it.
Alternatively, you can just try to set a stake in the ground for looking
forward and fixing those PV-specific problems hopefully once and for
all, like vbus and the kvm-connector tries to do. Sure, there will be
some degree of pain first as we roll out the subsystem and deploy
support, but thats true for lots of things. It's simply a platform
investment.
> An right now you can have a guest using pci to access a mix of
> userspace-emulated devices, userspace-emulated-but-kernel-accelerated
> virtio devices, and real host devices. All on one dead-end bus. Try
> that with vbus.
vbus is not interested in userspace devices. The charter is to provide
facilities for utilizing the host linux kernel's IO capabilities in the
most efficient, yet safe, manner possible. Those devices that fit
outside that charter can ride on legacy mechanisms if that suits them best.
>
>
>>>> I digress. My point here isn't PCI. The point here is the missing
>>>> component for when PCI is not present. The component that is partially
>>>> satisfied by vbus's devid addressing scheme. If you are going to use
>>>> vhost, and you don't have PCI, you've gotta build something to replace
>>>> it.
>>>>
>>>>
>>> Yes, that's why people have keyboards. They'll write that glue code if
>>> they need it. If it turns out to be a hit an people start having virtio
>>> transport module writing parties, they'll figure out a way to share
>>> code.
>>>
>> Sigh... The party has already started. I tried to invite you months
>> ago...
>>
>
> I've been voting virtio since 2007.
That doesn't have much to do with whats underneath it, since it doesn't
define these layers. See my stack diagram's for details.
>
>>> On the guest side, virtio-shmem.ko can unify the ring access. It
>>> probably makes sense even today. On the host side I eventfd is the
>>> kernel interface and libvhostconfig.so can provide the configuration
>>> when an existing ABI is not imposed.
>>>
>> That won't cut it. For one, creating an eventfd is only part of the
>> equation. I.e. you need to have originate/terminate somewhere
>> interesting (and in-kernel, otherwise use tuntap).
>>
>
> vbus needs the same thing so it cancels out.
No, it does not. vbus just needs a relatively simple single message
pipe between the guest and host (think "hypercall tunnel", if you will).
Per queue/device addressing is handled by the same conceptual namespace
as the one that would trigger eventfds in the model you mention. And
that namespace is built in to the vbus stack, and objects are registered
automatically as they are created.
Contrast that to vhost, which requires some other kernel interface to
exist, and to be managed manually for each object that is created. Your
libvhostconfig would need to somehow know how to perform this
registration operation, and there would have to be something in the
kernel to receive it, presumably on a per platform basis. Solving this
problem generally would probably end up looking eerily like vbus,
because thats what vbus does.
>
>>> Look at the virtio-net feature negotiation. There's a lot more there
>>> than the MAC address, and it's going to grow.
>>>
>> Agreed, but note that makes my point. That feature negotiation almost
>> invariably influences the device-model, not some config-space shim.
>> IOW: terminating config-space at some userspace shim is pointless. The
>> model ultimately needs the result of whatever transpires during that
>> negotiation anyway.
>>
>
> Well, let's see. Can vbus today:
>
> - let userspace know which features are available (so it can decide if
> live migration is possible)
yes, its in sysfs.
> - let userspace limit which features are exposed to the guest (so it can
> make live migration possible among hosts of different capabilities)
yes, its in sysfs.
> - let userspace know which features were negotiated (so it can transfer
> them to the other host during live migration)
no, but we can easily add ->save()/->restore() to the model going
forward, and the negotiated features are just a subcomponent if its
serialized stream.
> - let userspace tell the kernel which features were negotiated (when
> live migration completes, to avoid requiring the guest to re-negotiate)
that would be the function of the ->restore() deserializer.
> - do all that from an unprivileged process
yes, in the upcoming alacrityvm v0.3 with the ioctl based control plane.
> - securely wrt other unprivileged processes
yes, same mechanism plus it has a fork-inheritance model.
Bottom line: vbus isn't done, especially w.r.t. live-migration..but that
is not an valid argument against the idea if you believe in
release-early/release-often. kvm wasn't (isn't) done either when it was
proposed/merged.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* [GIT]: Networking
From: David Miller @ 2009-09-25 21:31 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Forgotten GIT 'add' in CAN driver commit, my bad.
2) AX25 control block refcounting is hosed, fix from Jarek Poplawski.
3) virtio_net driver updates from Rusty Russel
4) TI Davinci checks interrupt pending status wrongly. From Sriram @ TI.
Please pull, thanks a lot!
The following changes since commit 53cddfcc0e760d2b364878b6dadbd0c6d087cfae:
Linus Torvalds (1):
Merge git://git.kernel.org/.../lethal/sh-2.6
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Amit Shah (1):
virtio_net: Check for room in the vq before adding buffer
David S. Miller (2):
Merge branch 'master' of ssh://master.kernel.org/.../rusty/linux-2.6-for-davem
at91_can: Forgotten git 'add' of at91_can.c
Jarek Poplawski (1):
ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
Rusty Russell (5):
virtio_net: skb_orphan() and nf_reset() in xmit path.
virtio_net: return NETDEV_TX_BUSY instead of queueing an extra skb.
virtio_net: don't free buffers in xmit ring
virtio_net: formalize skb_vnet_hdr
virtio_net: avoid (most) NETDEV_TX_BUSY by stopping queue early.
Sriram (1):
TI Davinci EMAC: Fix in vector definition for EMAC_VERSION_2
drivers/net/can/at91_can.c | 1186 ++++++++++++++++++++++++++++++++++++++++++++
drivers/net/davinci_emac.c | 9 +-
drivers/net/virtio_net.c | 229 ++++------
net/ax25/af_ax25.c | 27 +-
4 files changed, 1299 insertions(+), 152 deletions(-)
create mode 100644 drivers/net/can/at91_can.c
^ permalink raw reply
* [PATCH] 3c59x: Rework suspend and resume
From: Anton Vorontsov @ 2009-09-25 20:52 UTC (permalink / raw)
To: David Miller; +Cc: Rafael J. Wysocki, Alan Stern, linux-pm, netdev
As noticed by Alan Stern, there is still one issue with the driver:
we disable PCI IRQ on suspend, but other devices on the same IRQ
line might still need the IRQ enabled to suspend properly.
Nowadays, PCI core handles all power management work by itself, with
one condition though: if we use dev_pm_ops. So, rework the driver to
only quiesce 3c59x internal logic on suspend, while PCI core will
manage PCI device power state with IRQs disabled.
Suggested-by: Rafael J. Wysocki <rjw@sisk.pl>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/3c59x.c | 77 +++++++++++++++++++++++++--------------------------
1 files changed, 38 insertions(+), 39 deletions(-)
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 7cdd4b0..dee2320 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -799,52 +799,54 @@ static void poll_vortex(struct net_device *dev)
#ifdef CONFIG_PM
-static int vortex_suspend(struct pci_dev *pdev, pm_message_t state)
+static int vortex_suspend(struct device *dev)
{
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct net_device *ndev = pci_get_drvdata(pdev);
+
+ if (!ndev || !netif_running(ndev))
+ return 0;
+
+ netif_device_detach(ndev);
+ vortex_down(ndev, 1);
- if (dev && netdev_priv(dev)) {
- if (netif_running(dev)) {
- netif_device_detach(dev);
- vortex_down(dev, 1);
- disable_irq(dev->irq);
- }
- pci_save_state(pdev);
- pci_enable_wake(pdev, pci_choose_state(pdev, state), 0);
- pci_disable_device(pdev);
- pci_set_power_state(pdev, pci_choose_state(pdev, state));
- }
return 0;
}
-static int vortex_resume(struct pci_dev *pdev)
+static int vortex_resume(struct device *dev)
{
- struct net_device *dev = pci_get_drvdata(pdev);
- struct vortex_private *vp = netdev_priv(dev);
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct net_device *ndev = pci_get_drvdata(pdev);
int err;
- if (dev && vp) {
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
- err = pci_enable_device(pdev);
- if (err) {
- pr_warning("%s: Could not enable device\n",
- dev->name);
- return err;
- }
- pci_set_master(pdev);
- if (netif_running(dev)) {
- err = vortex_up(dev);
- if (err)
- return err;
- enable_irq(dev->irq);
- netif_device_attach(dev);
- }
- }
+ if (!ndev || !netif_running(ndev))
+ return 0;
+
+ err = vortex_up(ndev);
+ if (err)
+ return err;
+
+ netif_device_attach(ndev);
+
return 0;
}
-#endif /* CONFIG_PM */
+static struct dev_pm_ops vortex_pm_ops = {
+ .suspend = vortex_suspend,
+ .resume = vortex_resume,
+ .freeze = vortex_suspend,
+ .thaw = vortex_resume,
+ .poweroff = vortex_suspend,
+ .restore = vortex_resume,
+};
+
+#define VORTEX_PM_OPS (&vortex_pm_ops)
+
+#else /* !CONFIG_PM */
+
+#define VORTEX_PM_OPS NULL
+
+#endif /* !CONFIG_PM */
#ifdef CONFIG_EISA
static struct eisa_device_id vortex_eisa_ids[] = {
@@ -3191,10 +3193,7 @@ static struct pci_driver vortex_driver = {
.probe = vortex_init_one,
.remove = __devexit_p(vortex_remove_one),
.id_table = vortex_pci_tbl,
-#ifdef CONFIG_PM
- .suspend = vortex_suspend,
- .resume = vortex_resume,
-#endif
+ .driver.pm = VORTEX_PM_OPS,
};
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH net-next-2.6] cxgb3: Added private MAC address and provisioning packet handler for iSCSI
From: David Miller @ 2009-09-25 20:42 UTC (permalink / raw)
To: kxie; +Cc: swise, divy, rranjan, James.Bottomley, michaelc, linux-kernel,
netdev
In-Reply-To: <20090925.121242.184886085.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 25 Sep 2009 12:12:42 -0700 (PDT)
> From: kxie@chelsio.com
> Date: Thu, 24 Sep 2009 18:33:10 -0700
>
>> 00c487ed661c0904757a21b7c958eba59e68482a
>> [PATCH net-next-2.6] cxgb3: Added private MAC address and provisioning packet handler for iSCSI
>>
>> This patch added support of private MAC address per port and provisioning
>> packet handler for iSCSI traffic only.
>>
>> Acked-by: Karen Xie <kxie@chelsio.com>
>> Acked-by: Divy Le Ray <divy@chelsio.com>
>> Signed-off-by: Rakesh Ranjan <rranjan@chelsio.com>
>
> Applied, thanks.
This doesn't even build, reverting:
drivers/scsi/cxgb3i/cxgb3i_iscsi.c: In function ‘cxgb3i_host_set_param’:
drivers/scsi/cxgb3i/cxgb3i_iscsi.c:718: error: ‘struct port_info’ has no member named ‘iscsi_ipv4addr’
drivers/scsi/cxgb3i/cxgb3i_iscsi.c: In function ‘cxgb3i_host_get_param’:
drivers/scsi/cxgb3i/cxgb3i_iscsi.c:755: error: ‘struct port_info’ has no member named ‘iscsi_ipv4addr’
make[3]: *** [drivers/scsi/cxgb3i/cxgb3i_iscsi.o] Error 1
^ permalink raw reply
* Re: [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
From: Jarek Poplawski @ 2009-09-25 20:29 UTC (permalink / raw)
To: Bernard Pidoux
Cc: Ralf Baechle DL5RB, David Miller, Bernard Pidoux F6BVP,
Linux Netdev List, linux-hams
In-Reply-To: <4ABD1EF3.7040400@upmc.fr>
On Fri, Sep 25, 2009 at 09:50:11PM +0200, Bernard Pidoux wrote:
> Hi Jarek,
>
> patch applied to 2.6.31.1 kernel keeping your other AX25 debugging patches.
Actually, only one of them is for debugging.
>
> So far, so good !
Very strange...;-) It seems I might have been wrong and the previous
patch could actually fix those oopses. Then it would point at some
problems while starting netrom connections as the main suspect.
Thanks,
Jarek P.
^ permalink raw reply
* Re: [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
From: Bernard Pidoux @ 2009-09-25 19:50 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Ralf Baechle DL5RB, David Miller, Bernard Pidoux F6BVP,
Linux Netdev List, linux-hams
In-Reply-To: <20090925183504.GA3307@del.dom.local>
Hi Jarek,
patch applied to 2.6.31.1 kernel keeping your other AX25 debugging patches.
So far, so good !
Thanks.
Bernard Pidoux
Jarek Poplawski a écrit :
> On Fri, Sep 25, 2009 at 02:40:52PM +0100, Ralf Baechle DL5RB wrote:
>> On Fri, Sep 25, 2009 at 01:10:38PM +0000, Jarek Poplawski wrote:
>>
>>> This bug isn't responsible for these oopses here, but looks quite
>>> obviously. (I'm not sure if it's easy to test/hit with the common
>>> tools.)
>> The issue your patch fixes is obvious enough.
>
> Yes, with new code there would be no doubt. But here, if you know it's
> worked for some time, you wonder if you're not blind. |-)
>>> Jarek P.
>>> ------------>
>>> [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
>>>
>>> Use ax25_cb_put after ax25_find_cb in ax25_ctl_ioctl.
>>>
>>> Reported-by: Bernard Pidoux F6BVP <f6bvp@free.fr>
>>> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>> Reviewed-by: Ralf Baechle <ralf@linux-mips.org>
>>
> Thanks for reviewing,
> Jarek P.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" 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 net-next-2.6] cxgb3: Added private MAC address and provisioning packet handler for iSCSI
From: David Miller @ 2009-09-25 19:12 UTC (permalink / raw)
To: kxie; +Cc: swise, divy, rranjan, James.Bottomley, michaelc, linux-kernel,
netdev
In-Reply-To: <200909250133.n8P1XAZb030062@localhost.localdomain>
From: kxie@chelsio.com
Date: Thu, 24 Sep 2009 18:33:10 -0700
> 00c487ed661c0904757a21b7c958eba59e68482a
> [PATCH net-next-2.6] cxgb3: Added private MAC address and provisioning packet handler for iSCSI
>
> This patch added support of private MAC address per port and provisioning
> packet handler for iSCSI traffic only.
>
> Acked-by: Karen Xie <kxie@chelsio.com>
> Acked-by: Divy Le Ray <divy@chelsio.com>
> Signed-off-by: Rakesh Ranjan <rranjan@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
From: David Miller @ 2009-09-25 19:10 UTC (permalink / raw)
To: jarkao2; +Cc: ralf, f6bvp, bernard.pidoux, netdev, linux-hams
In-Reply-To: <20090925183504.GA3307@del.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Fri, 25 Sep 2009 20:35:04 +0200
> On Fri, Sep 25, 2009 at 02:40:52PM +0100, Ralf Baechle DL5RB wrote:
>> > [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
>> >
>> > Use ax25_cb_put after ax25_find_cb in ax25_ctl_ioctl.
>> >
>> > Reported-by: Bernard Pidoux F6BVP <f6bvp@free.fr>
>> > Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>>
>> Reviewed-by: Ralf Baechle <ralf@linux-mips.org>
>>
> Thanks for reviewing,
Applied.
^ permalink raw reply
* Re: [PATCH] drivers/net: ks8851 ethernet network driver - RESUBMIT
From: David Miller @ 2009-09-25 19:09 UTC (permalink / raw)
To: David.Choi; +Cc: greg, netdev, Charles.Li, Choi, jgarzik, shemminger
In-Reply-To: <C43529A246480145B0A6D0234BDB0F0D02127E@MELANITE.micrel.com>
This patch does not apply.
There is already a CONFIG_KS8851 and a drivers/net/ks8851.c driver
in Linus's tree right now. So it completely conflicts with your's
I'm getting burnt out going back and forth trying to apply this
patch and it doesn't apply cleanly or there's already a driver
with that name etc.
This is a complete mess and a very poor driver submission.
Please get things straight, look at how other developers write
their commit messages and signoffs (your's was in bad style and
the signoff was not in the format described in
linux/Documentation/SubmittingPatches, for example).
^ permalink raw reply
* Re: [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
From: Jarek Poplawski @ 2009-09-25 18:35 UTC (permalink / raw)
To: Ralf Baechle DL5RB
Cc: David Miller, Bernard Pidoux F6BVP, Bernard Pidoux,
Linux Netdev List, linux-hams
In-Reply-To: <20090925134052.GA1661@linux-mips.org>
On Fri, Sep 25, 2009 at 02:40:52PM +0100, Ralf Baechle DL5RB wrote:
> On Fri, Sep 25, 2009 at 01:10:38PM +0000, Jarek Poplawski wrote:
>
> > This bug isn't responsible for these oopses here, but looks quite
> > obviously. (I'm not sure if it's easy to test/hit with the common
> > tools.)
>
> The issue your patch fixes is obvious enough.
Yes, with new code there would be no doubt. But here, if you know it's
worked for some time, you wonder if you're not blind. |-)
>
> > Jarek P.
> > ------------>
> > [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
> >
> > Use ax25_cb_put after ax25_find_cb in ax25_ctl_ioctl.
> >
> > Reported-by: Bernard Pidoux F6BVP <f6bvp@free.fr>
> > Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>
> Reviewed-by: Ralf Baechle <ralf@linux-mips.org>
>
Thanks for reviewing,
Jarek P.
^ permalink raw reply
* Re: [PULL] virtio_net updates
From: David Miller @ 2009-09-25 18:09 UTC (permalink / raw)
To: rusty; +Cc: netdev, herbert, markmc, dineshs, amit.shah
In-Reply-To: <200909241005.59416.rusty@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Thu, 24 Sep 2009 10:05:58 +0930
> Now Linus has the prereq add_buf changes, these can all feed via
> you. Note that the driver is changed to return TX_BUSY first which
> is simplest, then complicated again to avoid it.
Pulled, thanks a lot!
^ permalink raw reply
* Re: [PATCH 13/13] TProxy: use the interface primary IP address as a default value for --on-ip
From: Balazs Scheidler @ 2009-09-25 18:07 UTC (permalink / raw)
To: Brian Haley; +Cc: netfilter-devel, netdev
In-Reply-To: <4AB8DC6F.90602@hp.com>
On Tue, 2009-09-22 at 10:17 -0400, Brian Haley wrote:
> Balazs Scheidler wrote:
> > On Mon, 2009-09-21 at 14:00 -0400, Brian Haley wrote:
> >> Balazs Scheidler wrote:
> >>> #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> >>> +
> >>> +static inline const struct in6_addr *
> >>> +tproxy_laddr6(struct sk_buff *skb, const struct in6_addr *user_laddr, const struct in6_addr *daddr)
> >>> +{
> >>> + struct inet6_dev *indev;
> >>> + struct inet6_ifaddr *ifa;
> >>> + struct in6_addr *laddr;
> >>> +
> >>> + if (!ipv6_addr_any(user_laddr))
> >>> + return user_laddr;
> >>> +
> >>> + laddr = NULL;
> >>> + rcu_read_lock();
> >>> + indev = __in6_dev_get(skb->dev);
> >>> + if (indev && (ifa = indev->addr_list)) {
> >>> + laddr = &ifa->addr;
> >>> + }
> >>> + rcu_read_unlock();
> >>> +
> >>> + return laddr ? laddr : daddr;
> >>> +}
> >> You should call ipv6_dev_get_saddr() to get a source address based on the target
> >> destination address.
> >
> > Thanks for this hint, however this is not selecting a source address for
> > a given destination, rather it selects the address where tproxy is
> > redirecting the connection in case the user specified no --on-ip
> > parameter.
> >
> > e.g.
> >
> > ip6tables -A PREROUTING -p tcp --dport 80 -j TPROXY --on-port 50080
> >
> > This should redirect the connection to the primary IP address of the
> > incoming interface. In fact I spent 2 hours to figure out how to find
> > the proper address, and at the end I used the first IP address
> > configured to the interface, seeing that those addresses are sorted in
> > 'scope' order, e.g. link-local and site-local addresses are at the end
> > of the list, thus the front should be ok.
>
> Yes, the addresses are sorted by scope, but just because they're in the
> list doesn't mean they can be used, for example that address might have
> failed DAD or be Deprecated. ipv6_dev_get_saddr() will follow the rules
> from RFC 3484 in picking the best address to use, or none if there isn't
> anything appropriate.
>
> > Since I'm not that much into IPv6, I'd appreciate some help, is
> > ipv6_dev_get_saddr(client_ip_address) indeed the best solution here?
>
> Probably. An alternative might be to use ip6_dst_lookup() (see tcp_v6_connect()),
> but a lot more code for you.
One question, how fast is ipv6_dev_get_saddr()? Since the TPROXY target
can execute on a per-packet path (although the socket match should take
care of packets that belong to already-established connections), this
may be performance critical. Is ipv6_dev_get_saddr() something that I
can call so often?
--
Bazsi
^ permalink raw reply
* Re: TCP stack bug related to F-RTO?
From: Ilpo Järvinen @ 2009-09-25 18:03 UTC (permalink / raw)
To: Joe Cao; +Cc: Ray Lee, Netdev, LKML
In-Reply-To: <773030.8168.qm@web63404.mail.re1.yahoo.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4869 bytes --]
On Fri, 25 Sep 2009, Joe Cao wrote:
> Thanks for the reply! Do you happen to know which patch fixed the
> problem?
You can find those patches from the stable queue git tree. I gave you hint
from what release to look from in the last mail. However, as 2.6.24 is
anyway obsolete my recommendation is that you should probably consider
upgrading to fix all the other bugs that have been found since 2.6.24 was
obsoleted.
> Is there a bug tracking system for linux kernel?
Nothing that knows everything about everything.
> I studied the FRTO code in latest kernel 2.6.31. It seems the problem
> is still there:
>
> 1. Every time a RTO fires, because tcp_is_sackfrto(tp) returns 1,
> tcp_use_frto() returns true. And the server tcp enters FRTO.
> 2. After the head of write queue is retransmitted, two new data packets
> are transmitted, the server receives two dup-ACKs. That will make the
> TCP enter tcp_enter_frto_loss(), however, that only rests ssthresh and
> some other fields.
Perhaps those other fields are far more important than you think... :-)
...Some retransmission would happen here as step 3.
> 3. After another longer RTO fires, because tcp_is_sackfrto(tp) returns
> 1, tcp_use_frto() again returns true. The stack enters FRTO again.
> 4. The above repeats and the stack couldn't retransmits the lost packets
> faster.
>
> Is my understanding above correct?
...No. All magic that happens in tcp_enter_frto_loss should be enough to
really do more than a single retransmission (that is, in any other than
2.6.24 series kernel). There was an unfortunate bug in this area in 2.6.24
which basically undoed the effect of correct actions tcp_enter_frto_loss
did which effectively prevented tcp_xmit_retransmit_queue from doing its
part.
--
i.
--- On Fri, 9/25/09, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> Subject: Re: TCP stack bug related to F-RTO?
> To: "Ray Lee" <ray-lk@madrabbit.org>
> Cc: "Joe Cao" <caoco2002@yahoo.com>, "Netdev" <netdev@vger.kernel.org>, "LKML" <linux-kernel@vger.kernel.org>, jcaoco2002@yahoo.com
> Date: Friday, September 25, 2009, 6:09 AM
> On Thu, 24 Sep 2009, Ray Lee wrote:
>
> > [adding netdev cc:]
> >
> > On Thu, Sep 24, 2009 at 10:43 AM, Joe Cao <caoco2002@yahoo.com>
> wrote:
> > >
> > > Hello,
> > >
> > > I have found the following behavior with
> different versions of linux
> > > kernel. The attached pcap trace is collected with
> server
> > > (192.168.0.13) running 2.6.24 and shows the
> problem. Basically the
> > > behavior is like this:
> > >
> > > 1. The client opens up a big window,
> > > 2. the server sends 19 packets in a row (pkt #14-
> #32 in the trace), but all of them are dropped due to some
> congestion.
> > > 3. The server hits RTO and retransmits pkt #14 in
> #33
> > > 4. The client immediately acks #33 (=#14), and
> the server (seems like to enter F-RTO) expends the window
> and sends *NEW* pkt #35 & #36.=A0 Timeoute is doubled to
> 2*RTO; The client immediately sends two Dup-ack to #35 and
> #36.
> > > 5. after 2*RTO, pkt #15 is retransmitted in #39.
> > > 6. The client immediately acks #39 (=#15) in #40,
> and the server continues to expand the window and sends two
> *NEW* pkt #41 & #42. Now the timeoute is doubled to 4
> *RTO.
> > > 8. After 4*RTO timeout, #16 is retransmitted.
> > > 9....
> > > 10. The above steps repeats for retransmitting
> pkt #16-#32 and each time the timeout is doubled.
> > > 11. It takes a long long time to retransmit all
> the lost packets and before that is done, the client sends a
> RST because of timeout.
> > >
> > > The above behavior looks like F-RTO is in effect.
> And there seems to
> > > be a bug in the TCP's congestion control and
> retransmission algorithm.
> > > Why doesn't the TCP on server (running 2.6.24)
> enter the slow start?
> > > Why should the server take that long to recover
> from a short period
> > > of packet loss?
> > >
> > > Has anyone else noticed similar problem before?
> If my analysis was
> > > wrong, can anyone gives me some pointers to
> what's really wrong and
> > > how to fix it?
>
> Yes, 2.6.24 is an obsoleted version with known wrongs in
> FRTO
> implementation. Fixes never when to 2.6.24 stable series as
> it was
> _already_ obsoleted when the problems where reported and
> found. The
> correct fixes may be found from 2.6.25.7 (.7 iirc) and are
> included from
> 2.6.26 onward too.
>
> Just in case you happen to run ubuntu based kernel from
> that era (of
> course you should be reporting the bug here then...), a
> word of warning:
> it seemed nearly impossible for them to get a simple thing
> like that
> fixed, I haven't been looking if they'd eventually come to
> some sensible
> conclusion in that matter or is it still unresolved (or
> e.g., closed
> without real resolution).
^ 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