[Top] [All Lists]

Re: Intel and TOE in the news

To: Alex Aizman <alex@xxxxxxxxxxxx>
Subject: Re: Intel and TOE in the news
From: Andi Kleen <ak@xxxxxx>
Date: 21 Feb 2005 12:37:56 +0100
Date: Mon, 21 Feb 2005 12:37:56 +0100
Cc: "'Leonid Grossman'" <leonid.grossman@xxxxxxxxxxxx>, "'rick jones'" <rick.jones2@xxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <200502210158.j1L1wcDD004318@xxxxxxxxxxxxxxxxx>
References: <20050220230713.GA62354@xxxxxx> <200502210158.j1L1wcDD004318@xxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Sun, Feb 20, 2005 at 05:57:56PM -0800, Alex Aizman wrote:
> That's what we do, simply because interrupts are coalesced. 
> > The function doesn't do the full packet 
> > processing,  but just stuffs the packet into a CPU queue that 
> > is processed at a lower priority interrupt (softirq). 
> There's the netif_rx's own per-packet overhead (including the call itself)
> that arguably could be optimized..

netif_rx should be pretty cheap. It could be probably optimized more
(e.g. no local_irq_save if you know you're comming from
a interrupt or somehow avoiding the atomic reference count
increase on the device), but I suspect there are other
areas that could be improved first.

> > Most interesting would be to use per CPU TX completion 
> > interrupts using MSI-X and avoid bouncing packets around between CPUs.
> Our experimental Linux driver already supports MSI and MSI-X (the latter not
> tested). Once/if multi-MSI support in Linux becomes available it'd be
> practically possible to scale TCP connections with a number of CPUs.

It's already available, although the API is still a bit clumpsy.

> Alternative: wait until Xframe II adapter w/MSI-X.. 

How does that help with MSI?


<Prev in Thread] Current Thread [Next in Thread>