On Wed, 2013-02-27 at 21:17 +0200, Eliezer Tamir wrote:
> On 27/02/2013 20:47, Tom Herbert wrote:
> > On Wed, Feb 27, 2013 at 10:13 AM, Stephen Hemminger
> > wrote:
> >>
> >> Have you looked at netmap? Seems like a cleaner user API for this.
> >>
> > That might be a bit orthogonal to this. I beli
On Wed, 27 Feb 2013 09:55:49 -0800
Eliezer Tamir wrote:
> This patchset adds the ability for the socket layer code to poll directly
> on an Ethernet device's RX queue. This eliminates the cost of the interrupt
> and context switch and with proper tuning allows us to get very close
> to the HW la
A dumb question: is bypassing tcpdump/netfilters/qdisc etc. what we
always want? Isn't this a security issue?
We are not bypassing any of the regular stack checks/hooks, we call the
normal netif_rx_skb().
correction, netif_receive_skb()
--
To unsubscribe from this list: send the line "uns
On 04/03/2013 09:37, Cong Wang wrote:
On 02/28/2013 01:55 AM, Eliezer Tamir wrote:
Open issues:
1. Find a way to avoid the need to change the sk and skb structs.
One big disadvantage of how we do this right now is that when a device is
removed, it's hard to prevent it from getting polled by a
On 02/28/2013 01:55 AM, Eliezer Tamir wrote:
Open issues:
1. Find a way to avoid the need to change the sk and skb structs.
One big disadvantage of how we do this right now is that when a device is
removed, it's hard to prevent it from getting polled by a socket
which holds a stale reference.
2
On 01/03/2013 23:24, David Miller wrote:
From: Eliezer Tamir
Date: Wed, 27 Feb 2013 09:55:49 -0800
This patchset adds the ability for the socket layer code to poll directly
on an Ethernet device's RX queue. This eliminates the cost of the interrupt
and context switch and with proper tuning all
> This is exactly the kind of approach that makes sense rather than
> trying to put entire TCP stacks in the network card firmware.
>
And should also obviate the need to put a full TCP stack in user space!
> Thanks again for doing this work and I look forward to applying
> this stuff once all the
From: Eliezer Tamir
Date: Wed, 27 Feb 2013 09:55:49 -0800
> This patchset adds the ability for the socket layer code to poll directly
> on an Ethernet device's RX queue. This eliminates the cost of the interrupt
> and context switch and with proper tuning allows us to get very close
> to the HW
On 27/02/2013 23:42, Ben Greear wrote:
On 02/27/2013 12:40 PM, Eliezer Tamir wrote:
On 27/02/2013 21:58, Rick Jones wrote:
On 02/27/2013 09:55 AM, Eliezer Tamir wrote:
*rx-usecs=0 is usually not useful in a production environment.
I would think that latency-sensitive folks would be using rx-
On 02/27/2013 12:40 PM, Eliezer Tamir wrote:
On 27/02/2013 21:58, Rick Jones wrote:
On 02/27/2013 09:55 AM, Eliezer Tamir wrote:
Performance numbers:
Kernel Config C3/6 rx-usecs TCP UDP
3.8rc6 typicaloff adaptive 37k 40k
3.8rc6 typicaloff 0*50k 56k
3.8rc6
On 27/02/2013 21:58, Rick Jones wrote:
On 02/27/2013 09:55 AM, Eliezer Tamir wrote:
Performance numbers:
Kernel Config C3/6 rx-usecs TCP UDP
3.8rc6 typicaloff adaptive 37k 40k
3.8rc6 typicaloff 0*50k 56k
3.8rc6 optimized off 0*61k 67k
3.8rc6 o
On 02/27/2013 09:55 AM, Eliezer Tamir wrote:
This patchset adds the ability for the socket layer code to poll directly
on an Ethernet device's RX queue. This eliminates the cost of the interrupt
and context switch and with proper tuning allows us to get very close
to the HW latency.
This is a fo
On 27/02/2013 20:47, Tom Herbert wrote:
On Wed, Feb 27, 2013 at 10:13 AM, Stephen Hemminger
wrote:
Have you looked at netmap? Seems like a cleaner user API for this.
That might be a bit orthogonal to this. I believe the intent it to
allow spin polling from socket calls without API change.
On Wed, Feb 27, 2013 at 10:13 AM, Stephen Hemminger
wrote:
>
> Have you looked at netmap? Seems like a cleaner user API for this.
>
That might be a bit orthogonal to this. I believe the intent it to
allow spin polling from socket calls without API change.
>
> There is a version for Linux, but it
Have you looked at netmap? Seems like a cleaner user API for this.
There is a version for Linux, but it needs work. My plan is to send it staging
(after merge window reopens).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
This patchset adds the ability for the socket layer code to poll directly
on an Ethernet device's RX queue. This eliminates the cost of the interrupt
and context switch and with proper tuning allows us to get very close
to the HW latency.
This is a follow up to Jesse Brandeburg's Kernel Plumbers
16 matches
Mail list logo
