The following reply was made to PR kern/155030; it has been noted by GNATS.
From: Martin Matuska
To: bug-follo...@freebsd.org, m...@freebsd.org
Cc:
Subject: Re: kern/155030: [igb] igb(4) DEVICE_POLLING does not work with carp(4)
Date: Fri, 20 Apr 2012 09:18:50 +0200
The problem was actually i
On 20.04.2012 01:12, Andre Oppermann wrote:
On 19.04.2012 22:34, K. Macy wrote:
This is indeed a big problem. I'm working (rough edges remain) on
changing the routing table locking to an rmlock (read-mostly) which
This only helps if your flows aren't hitting the same rtentry.
Otherwise you s
On 17.04.2012 01:29, Adrian Chadd wrote:
On 15 April 2012 23:33, Alexander V. Chernikov wrote:
On 16.04.2012 01:17, Adrian Chadd wrote:
Hi,
This has broken (at least) net80211 and bpf, with LOR:
Yes, it is. Please try the attached patch
Hi,
Hello!
Sorry for the late reply, answering for
On 20.04.2012 10:26, Alexander V. Chernikov wrote:
On 20.04.2012 01:12, Andre Oppermann wrote:
On 19.04.2012 22:34, K. Macy wrote:
If the number of peers is bounded then you can use the flowtable. Max
PPS is much higher bypassing routing lookup. However, it doesn't scale
>
From my experience
On 20.04.2012 08:35, Luigi Rizzo wrote:
On Fri, Apr 20, 2012 at 12:37:21AM +0200, Andre Oppermann wrote:
On 20.04.2012 00:03, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 11:20:00PM +0200, Andre Oppermann wrote:
On 19.04.2012 22:46, Luigi Rizzo wrote:
The allocation happens while the code has a
On Thursday, April 19, 2012 4:46:22 pm Luigi Rizzo wrote:
> What might be moderately expensive are the critical_enter()/critical_exit()
> calls around individual allocations.
> The allocation happens while the code has already an exclusive
> lock on so->snd_buf so a pool of fresh buffers could be a
Hi,
Never heard of it, thanks!
On 04/19/12 11:32, Svatopluk Kraus wrote:
Hi,
Use IP_RECVIF option.
For IP_SENDIF look at
http://lists.freebsd.org/pipermail/freebsd-net/2007-March/013510.html
I used the patch on my embedded FreeBSD 9.0 boxes and it works fine. I
modificated it slightly to matc
On Thu, Apr 19, 2012 at 11:06:38PM +0200, K. Macy wrote:
> On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo wrote:
> > On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
> >> >> This is indeed a big problem. ?I'm working (rough edges remain) on
> >> >> changing the routing table locking to an r
Comments inline below:
On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo wrote:
> On Thu, Apr 19, 2012 at 11:06:38PM +0200, K. Macy wrote:
>> On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo wrote:
>> > On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
>> >> >> This is indeed a big problem. ?I'm
Continuing my profiling on network performance, another place
were we waste a lot of time is if_ethersubr.c::ether_output()
In particular, from the beginning of ether_output() to the
final call to ether_output_frame() the code takes slightly
more than 210ns on my i7-870 CPU running at 2.93 GHz + T
> Thank you for the "allow tcp from me to any established" rule,
> I'll give it a try later.
Ok, I've tested this - no oddity/"frozen" connection. As expected.
This is an excerpt from the ruleset (ipfw show):
00101 4759 2588637 allow tcp from any to any established
00102 20612360 allow t
On Fri, Apr 20, 2012 at 11:55 AM, Dmitry S. Kasterin wrote:
>> Thank you for the "allow tcp from me to any established" rule,
>> I'll give it a try later.
>
> Ok, I've tested this - no oddity/"frozen" connection. As expected.
> This is an excerpt from the ruleset (ipfw show):
>
> 00101 4759 258
On Fri, 20 Apr 2012, K. Macy wrote:
On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo wrote:
The small penalty when flowtable is disabled but compiled in is
probably because the net.flowtable.enable flag is checked
a bit deep in the code.
The advantage with non-connect()ed sockets is huge. I don
13 matches
Mail list logo
