Muli Ben-Yehuda wrote:
>> Net result: zilch. No performance increase, no noticeable CPU
>> utilization
>> benefits. Nothing. So I dropped it.
>
>Do you have pointers to the patches perchance?
Muli, I've been looking for this code and it looks like it's gone.
I was using a Power5 system that
On Mon, Jul 09, 2007 at 12:06:40AM -0700, David Miller wrote:
> > That works, but isn't optimal when you have an isolation-capable
> > IOMMU and you want the full isolation properties of the IOMMU. If
> > you only flush the IOTLB when the allocator wraps around, a stale
> > entry in the IOTLB can
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Date: Sun, 8 Jul 2007 19:17:30 +0300
> On Fri, Jul 06, 2007 at 12:20:19PM -0700, David Miller wrote:
> > From: "Williams, Mitch A" <[EMAIL PROTECTED]>
> > Date: Fri, 6 Jul 2007 10:14:56 -0700
> >
> > > In my opinion, IOMMU table locking is the major issue
On Fri, Jul 06, 2007 at 12:20:19PM -0700, David Miller wrote:
> From: "Williams, Mitch A" <[EMAIL PROTECTED]>
> Date: Fri, 6 Jul 2007 10:14:56 -0700
>
> > In my opinion, IOMMU table locking is the major issue with this
> > type of architecture. Since both Intel and AMD are touting IOMMUs
> > for
On Fri, Jul 06, 2007 at 10:14:56AM -0700, Williams, Mitch A wrote:
> David Miller wrote:
> >> Okay, but then using SG lists makes skbuff's much bigger.
> >>
> >>fraglistscatterlistper skbuff
> >> 32 bit 8 20 +12 * 18 = +216!
> >> 64 bi
From: "Williams, Mitch A" <[EMAIL PROTECTED]>
Date: Fri, 6 Jul 2007 10:14:56 -0700
> In my opinion, IOMMU table locking is the major issue with this type of
> architecture. Since both Intel and AMD are touting IOMMUs for virtual-
> ization support, this is an issue that's going to need a lot of
>
David Miller wrote:
>> Okay, but then using SG lists makes skbuff's much bigger.
>>
>> fraglistscatterlistper skbuff
>> 32 bit 8 20 +12 * 18 = +216!
>> 64 bit 16 32 +16 * 18 = +288
>>
>> So never min
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Fri, 06 Jul 2007 17:43:46 +1000
> On Thu, 2007-07-05 at 17:15 -0700, David Miller wrote:
> > Also even with the scatterlist idea, we'd still need to do two
> > map calls, one for skb->data and one for the page vector.
>
> We could make skb->shinfo(skb
On Thu, 2007-07-05 at 17:15 -0700, David Miller wrote:
> Also even with the scatterlist idea, we'd still need to do two
> map calls, one for skb->data and one for the page vector.
We could make skb->shinfo(skb)->frags[0] the first segment and deprecate
skb->data and skb->len.
OK, you can stop hit
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 5 Jul 2007 17:00:51 -0700
> On Thu, 05 Jul 2007 16:43:08 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Stephen Hemminger <[EMAIL PROTECTED]>
> > Date: Thu, 05 Jul 2007 16:14:14 -0700
> >
> > > The scatterlist only needs 1
On Thu, 05 Jul 2007 16:43:08 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Thu, 05 Jul 2007 16:14:14 -0700
>
> > The scatterlist only needs 16 bits for length/offset because
> > PAGE_SIZE is 4K
> >
> > Signed-off-by: Stephen Hemminger <
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 05 Jul 2007 16:14:14 -0700
> The scatterlist only needs 16 bits for length/offset because
> PAGE_SIZE is 4K
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Unfortunately I don't think this can be done, even on i386.
It is legal to
> --- a/include/asm-i386/scatterlist.h 2007-07-05 14:37:11.0 -0700
> +++ b/include/asm-i386/scatterlist.h 2007-07-05 15:44:51.0 -0700
> @@ -5,9 +5,9 @@
>
> struct scatterlist {
> struct page *page;
> -unsigned intoffset;
> dma_addr_t
13 matches
Mail list logo