From: John Partridge <[EMAIL PROTECTED]>
Date: Wed, 01 Nov 2006 10:27:19 -0600
> Sorry, but I find this change a bit puzzling. The problem is
> particular to the PPB on the HCA and not Altix. I can't see anywhere
> that a PCI Config Write is required to block until completion, it is
> the driver a
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Thu, 26 Oct 2006 16:58:41 -0700
> > -Idrivers/infiniband/hw/nes/nes_tcpip/include
>
> I guess this is the mysterious TCP stack module.
What is this thing?
___
openib-general mailing list
openib-general@op
From: "Glenn Grundstrom" <[EMAIL PROTECTED]>
Date: Thu, 26 Oct 2006 19:14:19 -0500
> It is part of our connection manager and assists with connection setup
> and teardown only.
I fear this is exactly the kind of stuff that we didn't want
to see start going into the kernel, and we've resisted the
From: "Glenn Grundstrom" <[EMAIL PROTECTED]>
Date: Thu, 26 Oct 2006 19:06:23 -0500
> +#include "nes_tcpip/include/nes_sockets.h"
I want to know what in the world this nes_tcpip thing is?
___
openib-general mailing list
openib-general@openib.org
http://
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Tue, 24 Oct 2006 16:36:32 -0600
> This is only really a problem for setup (when we program the BARs), so
> it seems silly to enforce an ordering at any other time. Reluctantly, I
> must disagree with Jeff -- drivers need to fix this.
One thing is th
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Thu, 12 Oct 2006 21:12:06 +0200
> Quoting r. David Miller <[EMAIL PROTECTED]>:
> > Subject: Re: Dropping NETIF_F_SG since no checksum feature.
> >
> > Numbers?
>
> I created two subnets on to
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Wed, 11 Oct 2006 23:23:39 +0200
> With my patch, there is a huge performance gain by increasing MTU to 64K.
> And it seems the only way to do this is by S/G.
Numbers?
___
openib-general mailing list
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Wed, 11 Oct 2006 17:01:03 +0200
> Quoting Steven Whitehouse <[EMAIL PROTECTED]>:
> > > ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset,
> > > size_t size, int flags)
> > > {
> > > ssize_t res;
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Wed, 11 Oct 2006 11:05:04 +0200
> So, it seems that if I set NETIF_F_SG but clear NETIF_F_ALL_CSUM,
> data will be copied over rather than sent directly.
> So why does dev.c have to force set NETIF_F_SG to off then?
Because it's more efficient
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue, 10 Oct 2006 20:49:09 -0700
> David> non-sendfile() paths will generate big packets just fine,
> David> as long as the application is providing that much data.
>
> OK, cool. Will the big packets be non-linear skbs?
If you had SG enabled
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue, 10 Oct 2006 20:42:20 -0700
> On the other hand I'm not sure how useful such a netdevice would be --
> will non-sendfile() paths generate big packets even if the MTU is 64KB?
non-sendfile() paths will generate big packets just fine, as long
as the
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue, 10 Oct 2006 20:33:46 -0700
> Michael> My guess was, an extra pass over data is likely to be
> Michael> expensive - dirtying the cache if nothing else. But I do
> Michael> plan to measure that, and see.
>
> I don't get it -- where's th
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Wed, 11 Oct 2006 02:13:38 +0200
> Maybe I can patch linux to allow SG without checksum?
> Dave, maybe you could drop a hint or two on whether this is worthwhile
> and what are the issues that need addressing to make this work?
>
> I imagine it'
From: Steve Wise <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 13:28:49 -0500
> Dave/Roland, is this patchset about ready to go?
All 3 patches applied, thanks Steve.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listi
From: Steve Wise <[EMAIL PROTECTED]>
Date: Wed, 26 Jul 2006 11:15:43 -0500
> Dave, what do you think about removing the user-space stuff for the
> first round of integration? IE: Just add netevents and kernel hooks to
> generate them.
Sure.
___
openi
From: Ralph Campbell <[EMAIL PROTECTED]>
Date: Fri, 14 Jul 2006 15:27:07 -0700
> Note that the current design only supports one IOMMU type in a system.
> This could support multiple IOMMU types at the same time.
This is not true, the framework allows multiply such types
and in fact Sparc64 takes
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Wed, 12 Jul 2006 17:11:26 -0700
> A cleaner solution would be to make the dma_ API really use the device
> it's passed anyway, and allow drivers to override the standard PCI
> stuff nicely. But that would be major surgery, I guess.
Clean but expensiv
From: Ralph Campbell <[EMAIL PROTECTED]>
Date: Wed, 12 Jul 2006 16:29:27 -0700
> Currently, the ib_ipath driver requires that the mapping be
> one-to-one since there is no practical way to reverse IOMMU
> mappings.
You can maintain a hash table that maps DMA addresses back to kernel
mappings. De
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 17:44:05 -0700
> Then is prefetching in memcpy really that important to them.
Not really, the thread just blocks while waiting for memory.
On stores they do a cacheline fill optimization similar to
the powerpc.
> Relying on PCI-X device
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 17:28:50 -0700
> I thought that most PCI controllers (that is to say the things bridging
> PCI to the rest of the system) could do prefetching and/or that PCI-X
> (if not PCI, no idea about PCI-e) cards could issue multiple
> transacti
From: Bryan O'Sullivan <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 16:34:23 -0700
> I'm not quite following you, though I assume you're referring to Niagara
> or Rock :-) Are you saying a memcpy_nc would do worse than plain
> memcpy, or worse than some other memcpy-like routine?
It would do worse
From: Bryan O'Sullivan <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 14:59:37 -0700
> It could, indeed. In fact, we had that discussion here before I sent
> this patch in. It presumably wants to live in lib/, and acquire a more
> generic name. What name will capture the uncached-read-but-cached-wr
From: Bryan O'Sullivan <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 15:01:39 -0700
> The support for write combining in the kernel is not in a state where
> that makes any sense at the moment.
Please fix the generic code if it doesn't provide the facility
you need at the moment. Don't shoe horn it
From: Bryan O'Sullivan <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 14:41:29 -0700
> ipath_core-$(CONFIG_X86_64) += ipath_wc_x86_64.o
> +ipath_core-$(CONFIG_PPC64) += ipath_wc_ppc64.o
Again, don't put these kinds of cpu specific functions
into the infiniband driver. They are potentially globally
From: Bryan O'Sullivan <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2006 14:41:30 -0700
> +/*
> + * Copy data. Try not to pollute the dcache with the source data,
> + * because we won't be reading it again.
> + */
> +#if defined(CONFIG_X86_64)
> +void *ipath_memcpy_nc(void *dest, const void *src, size_t
Most of the folks capable of reviewing networking changes
listen in on the netdev@vger.kernel.org mailing list, not
here.
Thanks.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscrib
26 matches
Mail list logo
