Hello Andrey, Konstantin!
Please approve the following commit:
--
Update maximum number of tables available in ipfw to reflect
changes done in r233478.
Approved by: (mentor)
MFC after:3 days
--
--
WBR, Alexander
Index: sbin/ipfw/ipfw.8
===
On 11.06.2012 20:55, Kolasinski, Brent D. wrote:
On 6/9/12 5:01 AM, "Alexander V. Chernikov" wrote:
It should disappear after 5-10 minutes. We're using several FreeBSD v9
sensors with flowd and it seems to run fine (except first 5 minutes
while waiting for template). I&#x
On 03.07.2012 15:32, Andreas Nilsson wrote:
I just wondered what the status of table support for ipv6 in ipfw is?
"working"
Best regards
Andreas
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubsc
On 03.07.2012 15:50, Andreas Nilsson wrote:
On Tue, Jul 3, 2012 at 1:34 PM, Alexander V. Chernikov
mailto:melif...@freebsd.org>> wrote:
On 03.07.2012 15:32, Andreas Nilsson wrote:
I just wondered what the status of table support for ipv6 in
ipfw is?
"wo
On 03.07.2012 16:55, Andreas Nilsson wrote:
On Tue, Jul 3, 2012 at 1:53 PM, Alexander V. Chernikov
mailto:melif...@freebsd.org>> wrote:
Well, June 12 is newer than April 23, but perhaps it was commited to
10-current and awaiting mfc to 9-stable (and hopefully 9.1)?
Actually this was MF
Hello list!
I'm quite stuck with bad forwarding performance on many FreeBSD boxes
doing firewalling.
Typical configuration is E5645 / E5675 @ Intel 82599 NIC.
HT is turned off.
(Configs and tunables below).
I'm mostly concerned with unidirectional traffic flowing to single
interface (e.g. us
On 03.07.2012 20:55, Luigi Rizzo wrote:
On Tue, Jul 03, 2012 at 08:11:14PM +0400, Alexander V. Chernikov wrote:
Hello list!
I'm quite stuck with bad forwarding performance on many FreeBSD boxes
doing firewalling.
...
In most cases system can forward no more than 700 (or 1400) kpps whi
On 04.07.2012 00:27, Luigi Rizzo wrote:
On Tue, Jul 03, 2012 at 09:37:38PM +0400, Alexander V. Chernikov wrote:
...
Thanks, another good point. I forgot to merge this option from andre's
patch.
Another 30-40-50kpps to win.
not much gain though.
What about the other IPSTAT_INC counters ?
On 04.07.2012 01:29, Doug Barton wrote:
On 07/03/2012 14:44, Luigi Rizzo wrote:
On Tue, Jul 03, 2012 at 02:19:06PM -0700, Doug Barton wrote:
Just curious ... what's the MTU on your FreeBSD box, and the Linux box?
he is (correctly) using min-sized packets, and counting packets not bps.
In thi
On 04.07.2012 12:13, Doug Barton wrote:
On 07/03/2012 23:29, Alexander V. Chernikov wrote:
On 04.07.2012 01:29, Doug Barton wrote:
Just curious ... what's the MTU on your FreeBSD box, and the Linux box?
In this particular setup - 1500. You're probably meaning type of mbufs
On 04.07.2012 13:12, Luigi Rizzo wrote:
Alex,
i am sure you are aware that in FreeBSD we have netmap too
Yes, I'm aware of that :)
which is probably a lot more usable than packetshader
(hw independent, included in the OS, also works on linux...)
I'm actually not talking about usability and com
On 04.07.2012 23:37, Lev Serebryakov wrote:
Hello, Alexander.
You wrote 4 июля 2012 г., 12:46:09:
AVC> http://shader.kaist.edu/packetshader/ (and links there) are good example
AVC> of what is going on.
But HOW?! GPU has very high "preparation" and data transfer cost,
how it could be use
On 04.07.2012 19:48, Luigi Rizzo wrote:
On Wed, Jul 04, 2012 at 01:54:01PM +0400, Alexander V. Chernikov wrote:
On 04.07.2012 13:12, Luigi Rizzo wrote:
Alex,
i am sure you are aware that in FreeBSD we have netmap too
Yes, I'm aware of that :)
which is probably a lot more usable
On 06.07.2012 10:11, Luigi Rizzo wrote:
On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote:
On 04.07.2012 19:48, Luigi Rizzo wrote:
the thing discussed a few years ago (at least the one i took out of the
discussion) was that the counter fields in rules should hold the
index
On 17.07.2012 11:17, Hooman Fazaeli wrote:
May be slightly off-topic, but do you have tested (or have plans to test )
with bidirectional traffic?
Situation with bi-directional traffic is better (not sure how much). I'm
intentionally not testing this case to discover rough cases (like
contested
On 17.07.2012 01:22, Luigi Rizzo wrote:
On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote:
On 06.07.2012 10:11, Luigi Rizzo wrote:
On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote:
On 04.07.2012 19:48, Luigi Rizzo wrote:
well, it seems that the
On 17.07.2012 12:36, Alexander V. Chernikov wrote:
On 17.07.2012 01:22, Luigi Rizzo wrote:
On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote:
On 06.07.2012 10:11, Luigi Rizzo wrote:
On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote:
On 04.07.2012 19
On 17.07.2012 03:23, Konstantin Belousov wrote:
On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote:
On 06.07.2012 10:11, Luigi Rizzo wrote:
On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote:
On 04.07.2012 19:48, Luigi Rizzo wrote:
the thing discussed
On 17.07.2012 13:38, Alexander V. Chernikov wrote:
On 17.07.2012 12:36, Alexander V. Chernikov wrote:
On 17.07.2012 01:22, Luigi Rizzo wrote:
On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote:
On 06.07.2012 10:11, Luigi Rizzo wrote:
On Thu, Jul 05, 2012 at 05:40:37PM
On 17.07.2012 17:21, Eugene Grosbein wrote:
17.07.2012 06:23, Konstantin Belousov пишет:
I do not think that your 'per-cpu' counter are correct. The thread
migration or rescheduling causes the fetch or update of the wrong
per-cpu structure. This allows parallel updates with undefined
consequenc
On 20.07.2012 14:32, Venkat Duvvuru wrote:
Hi,
I'm trying to create a socket under AF_LINK family but freebsd is saying
that "protocol is not supported" while creating the socket.
Is AF_LINK not supported?
If you're doing this to send raw ethernet frames you have to use bpf(4)
instead.
/Venkat
On 25.07.2012 02:54, Philip Prindeville wrote:
Ok, dumb question... How do I map a routing entries rtm_flags back to a
IANAipRouteProtocol value?
Well, something like this can probably be used:
~RTF_GATEWAY maps to local (2), -- local interface
RTF_STATIC maps tonetmgmt (3),
der
>From 347690db1c4ecaf267f3c027e18ea38734d28d42 Mon Sep 17 00:00:00 2001
From: "Alexander V. Chernikov"
Date: Wed, 5 Sep 2012 13:09:16 +0400
Subject: [PATCH 1/2] Export pfil lock
---
share/man/man9/pfil.9 | 55 --
sys/n
On 01.10.2012 00:00, Dominic Blais wrote:
Hi,
Hello!
I was just wondering if there was anything new about the bug of default route
changing without warning... Is there any test I can do to help fixing it?
Can you be a bit more precise and specify FreeBSD version and address
family?
Are yo
PF.
So, are we talking about IPv4 or IPv6?
--
-Message d'origine-
De : Alexander V. Chernikov [mailto:melif...@freebsd.org]
Envoyé : 30 septembre 2012 16:31
À : Dominic Blais
Cc : freebsd-net@freebsd.org
Objet : Re: Default route destination changing without warning follow-up
grep gate;
sleep 1; done can help)
If this is reproducible, what actions precedes this change?
Maybe some ARP traffic on that interface, or interface
creation/deletion, or.. ?
Is route monitor completely silent when the change happens?
--
-Message d'origine-
De : Alexander V.
On 05.10.2012 15:47, Gleb Smirnoff wrote:
Hello,
once the pfil(9) API was introduced in FreeBSD, our main packet filter,
the ipfw(4) worked in host byte order, that's why the pfil(9) API was
violated: the AF_INET hooks were entered with packet in host byte order.
Moreover, when we put
On 10.10.2012 00:36, Guy Helmer wrote:
On Oct 8, 2012, at 8:09 AM, Guy Helmer wrote:
I'm seeing a consistent new kernel panic in FreeBSD 8.3:
I'm not seeing how bd_sbuf would be NULL here. Any ideas?
Since I've not had any replies, I hope nobody minds if I reply with more
information.
Thi
Hello list!
Currently there are some unnecessary code residing in netinet6/in6_rmx.c
causing performance degradation for IPv6 forwarding.
Initially it was merged from netinet/in_rmx.c but it seems it is totally
unused now due to different approach used in IPv6 redirects.
Code calls mtx_lock
Hello list!
Packets receiving code for both ixgbe and if_igb looks like the following:
ixgbe_msix_que
-- ixgbe_rxeof()
{
IXGBE_RX_LOCK(rxr);
while
{
get_packet;
-- ixgbe_rx_input()
{
++ IXGBE_RX_UNLOCK(rxr);
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 as it is done in the timer
routine in dummynet) to build a list of all the packets
that need to be sent to if_input(), and then call
if_input with the entire list outside the
On 15.10.2012 20:39, Jack Vogel wrote:
I did not want to add it back, there were problems that constrained me
to do so, although its
been some time, I'd be happy to do some testing again without and see.
We've got more than hundred routers/firewalls running under heavy load
without this lock
On 16.10.2012 00:48, Ryan Stone wrote:
On Mon, Oct 15, 2012 at 12:29 PM, Gleb Smirnoff wrote:
To me this unlock/lock looks like a legacy from times, when the driver
had a single mutex for both TX and RX parts.
And removing this re-locking in foo_rxeof() was one of the aims for separate
TX/RX l
On 15.10.2012 22:14, John Baldwin wrote:
On Monday, October 15, 2012 12:32:10 pm Gleb Smirnoff wrote:
On Mon, Oct 15, 2012 at 09:04:27AM -0400, John Baldwin wrote:
J> > 3) in practice taskqueue routine is a nightmare for many people since
J> > there is no way to stop "kernel {ix0 que}" thread ea
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
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
On 16.10.2012 17:20, Ryan Stone wrote:
On Tue, Oct 16, 2012 at 8:47 AM, Gleb Smirnoff wrote:
Can you please provide hints how can SIOCADDMULTI lead to obtaining RX
lock in the stock driver?
It doesn't. But it does acquire the core lock, and the core lock is
acquired before the RX lock (in ix
On 22.10.2012 05:43, Ryan Stone wrote:
On Sun, Oct 21, 2012 at 2:21 PM, Alexander V. Chernikov
wrote:
ix:rx -> udp is also fairly obvious (here's one backtrace):
The same question, where "udp" -> "ix:rx" can happen ?
It can't happen directly as far as I
Hello list!
Currently size of arp/ndp hash is the following:
#defineLLTBL_HASHTBL_SIZE 32 /* default 32 ? */
This may be OK for end hosts, but this is definitely not enough for
router howadays. Especially given that IPv6 hosts generate 2 ndp records.
Output from 2 random v4 / v6
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte
copying from arp record to packet ethernet header.
It seems that acquiring lle lock for fast path (main traffic flow) is
not necessary even with current code.
My tests shows ~10% improvement with this patch appli
On 08.11.2012 14:24, Andre Oppermann wrote:
On 08.11.2012 00:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte
copying from arp record to packet
ethernet header.
It seems that acquiring lle lock for fast path (main traffic flow
On 08.11.2012 14:17, Andre Oppermann wrote:
On 07.11.2012 23:48, Alexander V. Chernikov wrote:
Hello list!
Currently size of arp/ndp hash is the following:
#define LLTBL_HASHTBL_SIZE 32 /* default 32 ? */
This may be OK for end hosts, but this is definitely not enough for
router howadays
On 08.11.2012 03:46, Adrian Chadd wrote:
On 7 November 2012 15:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte copying
from arp record to packet ethernet header.
It seems that acquiring lle lock for fast path (main traffic flow
On 09.11.2012 12:51, Fabien Thomas wrote:
Le 8 nov. 2012 à 11:25, Alexander V. Chernikov a écrit :
On 08.11.2012 14:24, Andre Oppermann wrote:
On 08.11.2012 00:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte
copying from arp
On 09.11.2012 13:59, Fabien Thomas wrote:
Le 9 nov. 2012 à 10:05, Alexander V. Chernikov a écrit :
On 09.11.2012 12:51, Fabien Thomas wrote:
Le 8 nov. 2012 à 11:25, Alexander V. Chernikov a écrit :
On 08.11.2012 14:24, Andre Oppermann wrote:
On 08.11.2012 00:24, Alexander V. Chernikov
On 09.11.2012 20:51, Fabien Thomas wrote:
Le 9 nov. 2012 à 17:43, Ingo Flaschberger a écrit :
Am 09.11.2012 15:03, schrieb Fabien Thomas:
In in_arpinput only exclusive access to the entry is taken during the update no
IF_AFDATA_LOCK that's why i was surprised.
I'll update patch to reflect c
Hello list!
Currently most ipfw operations with dynamic states (keep-state,
check-state, limit) are serialized via IPFW_DYN_LOCK() which is per-vnet
mutex lock.
As a result, performance is limited to the same ~650kpps as in routing
(in several cases).
Patch changes the following:
* global lo
On 14.11.2012 00:16, Alfred Perlstein wrote:
Alexander, this is awesome.
On 11/13/12 11:28 AM, Alexander V. Chernikov wrote:
Hello list!
Currently most ipfw operations with dynamic states (keep-state,
check-state, limit) are serialized via IPFW_DYN_LOCK() which is
per-vnet mutex lock.
As a
On 14.11.2012 19:47, Gleb Smirnoff wrote:
On Tue, Nov 13, 2012 at 11:28:23PM +0400, Alexander V. Chernikov wrote:
A> So, we can do the following:
A> 1) lock increments/decrements via some separate mutex
A> 2) do nothing
A> 3) take some combined approach:
4) Take it via uma
On 27.11.2012 09:54, Gleb Smirnoff wrote:
On Tue, Nov 27, 2012 at 02:30:51AM +0400, Alexander V. Chernikov wrote:
A> On 14.11.2012 19:47, Gleb Smirnoff wrote:
A> > On Tue, Nov 13, 2012 at 11:28:23PM +0400, Alexander V. Chernikov wrote:
A> > A> So, we can do the following
On 10.06.2012 18:20, Alexander V. Chernikov wrote:
On 27.04.2012 03:44, Hiroki Sato wrote:
"Alexander V. Chernikov" wrote
in<4f96e71b.9020...@freebsd.org>:
me> On 24.04.2012 21:05, Hiroki Sato wrote:
Proof-of-concept patch attached.
Hopefully, libcap code is easily exte
On 03.12.2012 12:11, Gleb Smirnoff wrote:
On Sun, Dec 02, 2012 at 04:48:18AM +0400, Alexander V. Chernikov wrote:
A> On 10.06.2012 18:20, Alexander V. Chernikov wrote:
A> > On 27.04.2012 03:44, Hiroki Sato wrote:
A> >> "Alexander V. Chernikov" wrote
A> >>
On 06.12.2012 13:13, Ermal Luçi wrote:
Hello,
i was looking at ipfw dynamic code for dynamic states/rules and see that it
unconditionally schedules a callout even if there is not work to do.
Wouldn't it be best to reschedule it when there is something to do to avoid
having a useless
callout/eve
On 07.12.2012 16:27, Andrey V. Elsukov wrote:
Hi All,
We have discovered that ipfw(4) shows very low performance results with
our rules. One of the biggest problems is rules with O_IP6_XXX_ME
opcode. They checks match or not match packet's addresses with locally
configured IPv6 addresses.
For I
On 13.12.2012 15:46, Andriy Gapon wrote:
ng_ether uses if_xname for naming its nodes.
This could be troublesome for mapping interface names to their ng_ether
companions
in the face of interface renaming capability. Especially given that interface
renaming and ng_ether _module_ loading may happ
On 01.02.2013 10:09, Vijay Singh wrote:
> I see that BPFIF_LOCK() in bpf_mtap() is getting invoked, even
> though I am not tracing the interface. Is this expected?
This should not happen, since BPF_MTAP macro checks if BFP consumers
are present (via bpf_peers_present()) before calling bpf_mtap.
Bt
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, co...@211.ru
Cc:
Subject: Re: kern/134931: [route] Route messages sent to all socket listeners
regardless of setfib(1)
Date: Sun, 31 Oct 2010 10:2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ferruccio Zamuner wrote:
> Ciao,
>
> I was trying to configure my host with IPv6.
>
> I've verified:
>
> 1)
> options INET6 # IPv6 communications protocols
> exists in /usr/src/sys/amd64/conf/MYKERNEL, and it is.
>
> 2) in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At the moment the only possible way to set packet fib from userland is
ipfw(8) setfib rule. Since no 'setfib tablearg' exists ruleset grows
with every fib.
Additionally, there is no way to set packet fib before netgraph
processing: L2 ipfw hook is call
On 18.05.2011 16:31, JACK wrote:
After inserting the following IPv4 routers:
0x360AD0A2/30
0x360ADFEC/20
0x360AD082/30
I try to delete the above routes, when delete the second
route(0x360ADFEC/20), the operation fail.
Can you specify exact commands you are issuing to add/remove routes?
(or "ro
ode in
rtrequest1_fib does this via rt_maskedcopy().
Are you sure you need to pass
0x360AD0A2/30
0x360ADFEC/20
0x360AD082/30
instead of:
0x360AD0A0/30
0x360AD000/20
0x360AD080/30
?
> ____
> 发件人: Alexander V. Chernikov [melif...@ipfw.ru]
> 发送时间: 2011年
On 03.06.2011 18:04, Pawel Tyll wrote:
Hi list,
I've mailed FreeBSD Foundation about this, but for wider exposure this
seems like a good place too.
We are currently looking for some hardware solution that supports MPLS
and VPLS tunnels for IP and PPPoE (at the same end-point interface).
While t
Hello list!
At the moment multiple fib support is completely broken in route(4)
(described in kern/134931)
Linux supports fibs via its netlink protocol. OpenBSD makes rtsock
version bump for the same for a while ago.
Since 9.0 is approaching it is a good time to make some changes to
routing s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rafael Ganascim wrote:
> Hi list,
>
> I'm planning and testing a new FreeBSD router, with vlans and carp
> interfaces. There are a lot of vlans, with high vlan IDs. We have, for
> example:
>
> dot1q vlan id: 1530
>
> Iface igb0
> vlan1530
> carp1
e this can be
done some other way?
>
> Thanks!
>
> 2011/6/20 Alexander V. Chernikov
>
> Rafael Ganascim wrote:
>>>> Hi list,
>>>>
>>>> I'm planning and testing a new FreeBSD router, with vlans and carp
>>>> interfaces. There are a lo
The following reply was made to PR kern/127057; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, sa...@system.pl
Cc:
Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket
to IPv4 mapped address
Date: Sun, 26 Jun 2011 15:1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiroki Sato wrote:
> Vlad Galu wrote
> in :
>
> du> Hello,
> du>
> du> A couple of years ago, Stef Walter proposed a patch[1] that enforced
> du> the scope of routing messages. The general consesus was that the best
> du> approach would be the Open
On 17.08.2011 13:52, M. V. wrote:
hi,
as part of a project, i need to have an E1 card with usual functionalities
(channelized E1 with HDLC support) in FreeBSD. i searched a lot, but i found no
E1 card that has FreeBSD driver (or any instructions for configuration of an E1
card in FreeBSD).
Y
Hello list!
FreeBSD supports IP_MINTTL since long ago (5.x ?). This is
RFC3682-compatible implementation.
It is very simple: if we can associate incoming packet with any socket,
socket is checked for minimum TTL value existence. If such value exists
and received packet TTL is lower, packet i
On 07.09.2011 11:17, Julian Elischer wrote:
On 7/16/11 5:43 AM, Vlad Galu wrote:
Hello,
Hello!
A couple of years ago, Stef Walter proposed a patch[1] that enforced
the scope of routing messages. The general consesus was that the best
approach would be the OpenBSD way - transporting the FIB nu
lity.
Particularly I'm trying to figure out how can I use all this variety of
filters to get MPLS traffic split to different RX queues.
Maybe someone can point me to the right direction?
--
Alexander V. Chernikov
Yandex NOC
___
freebsd-net
grarpamp wrote:
Wouldn't it be better to support the obvious formal emergent standards
track protocol instead of the legacy informational one? Or to perform
both via sysctl or other arguments/defines, with the standard IPFIX
being the default mode? Have you reviewed the nProbe code for other
vari
Дмитрий Замураев wrote:
If you can, add information abount AS numbers too.
ASN patch for 16-bit ASN's for V5 protocol:
http://www.stasyan.com/devel/ng_netflow/patch_asnum_1
Proto V5 can't handle 32-bit ASN unlike V9.
But I can't understand why it's not working for me,
AS numbers exists for first
The following reply was made to PR kern/127057; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, sa...@system.pl
Cc:
Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket
to IPv4 mapped address
Date: Thu, 24 Jun 2010 19:4
The following reply was made to PR kern/127057; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, sa...@system.pl
Cc:
Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket
to IPv4 mapped address
Date: Thu, 24 Jun 2010 19:5
Hello all.
I'm currently working on to enhance ipfw in some areas.
The most notable (and user-visible) change is named table support.
The other one is support for different lookup algorithms for different
key types.
For example, new ipfw permits writing this:
ipfw table tb1 create type cidr
ipfw
On 02.08.2014 10:33, Luigi Rizzo wrote:
>
>
>
> On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov
> mailto:melif...@freebsd.org>> wrote:
>
> Hello all.
>
> I'm currently working on to enhance ipfw in some areas.
> The most notable
On 02.08.2014 12:33, Alexander V. Chernikov wrote:
On 02.08.2014 10:33, Luigi Rizzo wrote:
On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov
mailto:melif...@freebsd.org>> wrote:
Hello all.
I'm currently working on to enhance ipfw in some areas.
The most n
On 04.08.2014 15:58, Luigi Rizzo wrote:
> On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote:
>> On 02.08.2014 12:33, Alexander V. Chernikov wrote:
>>> On 02.08.2014 10:33, Luigi Rizzo wrote:
>>>>
>>>>
>>>> O
Hello list.
(sorry for posting twice, patch seems to be too big to be posted as
attachment).
I've been hacking ipfw for a while and It seems there is something ready
to test/review in projects/ipfw branch.
Main user-visible changes are related to tables:
1) Tables are now identified by nam
On 14.08.2014 13:23, Luigi Rizzo wrote:
On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru>> wrote:
Hello list.
I've been hacking ipfw for a while and It seems there is something
ready to test/review in projects/ipfw branch.
On 14.08.2014 14:44, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru>> wrote:
On 14.08.2014 13:23, Luigi Rizzo wrote:
On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru&g
On 14.08.2014 15:15, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru>> wrote:
On 14.08.2014 14:44, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru&g
On 14.08.2014 16:08, Marko Zec wrote:
On Thu, 14 Aug 2014 15:52:34 +0400
"Alexander V. Chernikov" wrote:
On 14.08.2014 15:15, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru>> wrote:
On 14.08.2014 14:44, L
On 14.08.2014 16:08, Willem Jan Withagen wrote:
On 2014-08-14 13:15, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov <
melif...@yandex-team.ru> wrote:
On 14.08.2014 14:44, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov &
On 14.08.2014 15:52, Alexander V. Chernikov wrote:
> On 14.08.2014 15:15, Luigi Rizzo wrote:
>>
>>
>>
>> On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov
>> mailto:melif...@yandex-team.ru>> wrote:
>>
>> On 14.08.2014 14:44, Luigi Rizzo
On 08.08.2014 16:11, Dmitry Selivanov wrote:
04.08.2014 23:51, Alexander V. Chernikov пишет:
On 04.08.2014 15:58, Luigi Rizzo wrote:
On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote:
On 02.08.2014 12:33, Alexander V. Chernikov wrote:
On 02.08.2014 10:33, Luigi Rizzo
On 15.08.2014 18:19, Dmitry Selivanov wrote:
15.08.2014 17:25, Alexander V. Chernikov пишет:
On 08.08.2014 16:11, Dmitry Selivanov wrote:
04.08.2014 23:51, Alexander V. Chernikov пишет:
On 04.08.2014 15:58, Luigi Rizzo wrote:
On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov
Hello Jack!
Can you please commit (or let me commit) the following one-liner?
Index: sys/dev/ixgbe/ixgbe.c
===
--- sys/dev/ixgbe/ixgbe.c (revision 270040)
+++ sys/dev/ixgbe/ixgbe.c (working copy)
@@ -1055,7 +1055,7 @@ ixgbe_ioctl(str
Hello list.
It seems that networking is evolving quite rapidly, so 10g nics are
quite common: we have Intel, Chelsio, Mellanox, Emulex, Solarflare and
Myricom drivers in our tree (maybe some others). 40G are also here:
(Chelsio, Mellanox, Intel). Things like 25G NICs are also getting more
interest
On 15.08.2014 19:20, Alexander V. Chernikov wrote:
On 15.08.2014 18:19, Dmitry Selivanov wrote:
15.08.2014 17:25, Alexander V. Chernikov пишет:
On 08.08.2014 16:11, Dmitry Selivanov wrote:
04.08.2014 23:51, Alexander V. Chernikov пишет:
On 04.08.2014 15:58, Luigi Rizzo wrote:
On Mon, Aug 04
On 19.08.2014 20:06, Dmitry Selivanov wrote:
19.08.2014 17:50, Alexander V. Chernikov пишет:
On 15.08.2014 19:20, Alexander V. Chernikov wrote:
On 15.08.2014 18:19, Dmitry Selivanov wrote:
15.08.2014 17:25, Alexander V. Chernikov пишет:
On 08.08.2014 16:11, Dmitry Selivanov wrote
On 28.08.2014 12:31, Eggert, Lars wrote:
Hi,
no matter what value I bump kern.ipc.nmbclusters and kern.ipc.nmbufs to, I still get
"requests for mbufs denied" with igb interfaces, and the occasional connection
stall, even when dialing down hw.igb.num_queues=1:
[root@laurel: ~] netstat -m
3070/
Hello list.
I'd like to commit some changes to lagg counters which might be worth
discussion.
Diff is available at https://reviews.freebsd.org/D781
Quoting its summary:
While counting packets using per-cpu counters might not introduce
any significant overhead at current rates, we do not need to
On 22.09.2014 23:46, Adrian Chadd wrote:
> Hi,
>
> Yes.
>
> * grab an ixgbe NIC and the -HEAD driver; (or cxgbe - I haven't gone
> and written RSS programming code for that just yet);
> * patch it to use a symmetric RSS key;
> * configure up N queues;
> * run an instance of snort on each TX/RX ri
On 23.09.2014 18:44, Luigi Rizzo wrote:
On Tue, Sep 23, 2014 at 4:36 PM, Adrian Chadd <mailto:adr...@freebsd.org>> wrote:
On 23 September 2014 01:36, Alexander V. Chernikov
mailto:melif...@freebsd.org>> wrote:
> On 22.09.2014 23:46, Adrian Chad
On 23.09.2014 19:46, Luigi Rizzo wrote:
On Tue, Sep 23, 2014 at 07:17:08PM +0400, Alexander V. Chernikov wrote:
On 23.09.2014 18:44, Luigi Rizzo wrote:
...
However, in addition to non-symmetric RSS (which is hopefully being
addressed), there is another
usual "producer - multuple cons
On 23.09.2014 20:00, Adrian Chadd wrote:
Ah, this behaviour.
It's called DROP_EN on the intel igb / ixgbe hardware. Grep the
drivers for that particular register bit/setting.
Set that bit for an RX queue and it'll instruct the MAC to drop frames
destined if that RX ring is full to it and keep r
On 03.10.2014 04:40, Hariprasad S wrote:
HI,
Detaching the slave from the lagg interface which has vlan on top of it, hits
an panic.
Kernel used: FreeBSD HEAD r272051
Is anyone aware of this issue?
Yes. What is happening here:
We acquire lagg WLOCK to set new link layer address (due to "mast
Hi,
I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
What has changed:
Main user-visible changes are related to tables:
* Tables are now identified by names, not numbers. There can be up to
65k tables with up to 63-byte long names.
* Tables are now set-aware (defaul
101 - 200 of 284 matches
Mail list logo
