Re: ixgbe & if_igb RX ring locking

2012-10-19 Thread Fabien Thomas
Le 18 oct. 2012 à 20:09, Jack Vogel a écrit : > On Thu, Oct 18, 2012 at 6:20 AM, Andre Oppermann wrote: > >> On 13.10.2012 20:22, Luigi Rizzo wrote: >> >>> On Sat, Oct 13, 2012 at 09:49:21PM +0400, Alexander V. Chernikov wrote: >>> Hello list! Packets receiving code for b

kern/94020: [tcp] tcp_timer_2msl_tw NULL pointer dereference panic

2012-10-19 Thread Sun Keyong
Hi, Recently I meet a bug about the tcp_timer_2msl_tw null pointer dereference panic. I found there is a PR94020, the status was closed. Could anyone point to me how to fix this, and where I can found how to fix? Thanks a lot KY ___ freebsd-net@freebsd.

Re: CARP on vSwitch

2012-10-19 Thread Simon Dick
On 18 October 2012 21:59, Rafael Henrique Faria wrote: > Hi, I'm trying to use CARP on two FreeBSD servers in a ESX environment. But > it's not working. > > The problem is that every frame sent from CARP gets back to the same host. > This is an old problem: > > http://www.mail-archive.com/freebsd-

Re: A small cleanup patch

2012-10-19 Thread Andre Oppermann
On 18.10.2012 19:00, Konstantin Belousov wrote: On Thu, Oct 18, 2012 at 04:09:33PM +0200, Andre Oppermann wrote: On 05.10.2012 01:21, Vijay Singh wrote: Folks, I came up with this while going through the lltable code. Thank you. I just purged a larger number of stray spl* from the net*/* dire

[RFC] Enabling IPFIREWALL_FORWARD in run-time

2012-10-19 Thread Andrey V. Elsukov
Hi All, Many years ago i have already proposed this feature, but at that time several people were against, because as they said, it could affect performance. Now, when we have high speed network adapters, SMP kernel and network stack, several locks acquired in the path of each packet, and i have a

Re: A small cleanup patch

2012-10-19 Thread Konstantin Belousov
On Fri, Oct 19, 2012 at 11:15:00AM +0200, Andre Oppermann wrote: > On 18.10.2012 19:00, Konstantin Belousov wrote: > > On Thu, Oct 18, 2012 at 04:09:33PM +0200, Andre Oppermann wrote: > >> On 05.10.2012 01:21, Vijay Singh wrote: > >>> Folks, I came up with this while going through the lltable code.

Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time

2012-10-19 Thread Zamri Besar
On Oct 19, 2012 7:25 PM, "Andrey V. Elsukov" wrote: > > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and network stac

Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time

2012-10-19 Thread Andre Oppermann
On 19.10.2012 13:25, Andrey V. Elsukov wrote: Hi All, Many years ago i have already proposed this feature, but at that time several people were against, because as they said, it could affect performance. Now, when we have high speed network adapters, SMP kernel and network stack, several locks a

Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time

2012-10-19 Thread Andrey V. Elsukov
On 19.10.2012 16:02, Andre Oppermann wrote:>> http://people.freebsd.org/~ae/pfil_forward.diff >> >> Also we have done some tests with the ixia traffic generator connected >> via 10G network adapter. Tests have show that there is no visible >> difference, and there is no visible performance degradat

Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time

2012-10-19 Thread Ian Smith
On Fri, 19 Oct 2012 15:25:24 +0400, Andrey V. Elsukov wrote: > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and

Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time

2012-10-19 Thread Andre Oppermann
On 19.10.2012 14:18, Andrey V. Elsukov wrote: On 19.10.2012 16:02, Andre Oppermann wrote:>> http://people.freebsd.org/~ae/pfil_forward.diff Also we have done some tests with the ixia traffic generator connected via 10G network adapter. Tests have show that there is no visible difference, and th

Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time

2012-10-19 Thread Alexander V. Chernikov
On 19.10.2012 18:05, Andre Oppermann wrote: On 19.10.2012 14:18, Andrey V. Elsukov wrote: On 19.10.2012 16:02, Andre Oppermann wrote:>> http://people.freebsd.org/~ae/pfil_forward.diff Also we have done some tests with the ixia traffic generator connected via 10G network adapter. Tests have sho

Re: ixgbe & if_igb RX ring locking

2012-10-19 Thread Alexander V. Chernikov
On 17.10.2012 18:06, John Baldwin wrote: On Monday, October 15, 2012 9:04:27 am John Baldwin wrote: On Monday, October 15, 2012 10:10:40 am Alexander V. Chernikov wrote: On 13.10.2012 23:24, Jack Vogel wrote: On Sat, Oct 13, 2012 at 11:22 AM, Luigi Rizzo wrote: one option could be (same a

Re: ixgbe & if_igb RX ring locking

2012-10-19 Thread Jack Vogel
On Fri, Oct 19, 2012 at 8:23 AM, Alexander V. Chernikov < melif...@freebsd.org> wrote: > On 17.10.2012 18:06, John Baldwin wrote: > >> On Monday, October 15, 2012 9:04:27 am John Baldwin wrote: >> >>> On Monday, October 15, 2012 10:10:40 am Alexander V. Chernikov wrote: >>> On 13.10.2012 23:2

Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time

2012-10-19 Thread Julian Elischer
On 10/19/12 4:25 AM, Andrey V. Elsukov wrote: Hi All, Many years ago i have already proposed this feature, but at that time several people were against, because as they said, it could affect performance. Now, when we have high speed network adapters, SMP kernel and network stack, several locks a

Re: CARP on vSwitch

2012-10-19 Thread Guy Helmer
On Oct 18, 2012, at 3:59 PM, Rafael Henrique Faria wrote: > Hi, I'm trying to use CARP on two FreeBSD servers in a ESX environment. But > it's not working. > > The problem is that every frame sent from CARP gets back to the same host. > This is an old problem: > > http://www.mail-archive.com/

Debian Bug#690986: CVE-2012-5363 CVE-2012-5365

2012-10-19 Thread Steven Chamberlain
Hi, On 19/10/12 20:34, Moritz Muehlenhoff wrote: > Two security issues were found in the kfreebsd network stack: > http://www.openwall.com/lists/oss-security/2012/10/10/8 > Issue #1 was assigned CVE-2012-5363 > Issue #2 was assigned CVE-2012-5365 Thank you for mentioning it. Issue #2 seems simi