Hi Eitan,
Thank your for your response.
the ioctl is the example was in Luigi netmap page... maybe Luigi can help
here???
can you say why the print's are wrong?
i fetched wrking headers from other tools without too much checking, maybe
some
are irrelevant but for my tests i didn't worry abou
[ please bottom post or reply inline ]
On 25 April 2013 17:48, Sami Halabi wrote:
> Okay,
> i figured out the includes, now it runs and seg faults:
Don't forget to show the working headers ;)
> any ideas?
>
> here is the new code:
> int main() {
>
> struct netmap_if *nifp = NULL;
> struct nmreq
How many pf rules do you have?. And, as I asked in my previous post, do you
create states on both sides of the firewall?
One interface has 12 rules and other other interface has one rule. We
do create states on both sides.
___
freebsd-net@freebsd.or
Dnia czwartek, 25 kwietnia 2013 o 20:24:26 Erich Weiler napisał(a):
> > As far as I understand, processing of packets by pf takes place in
> > receiving network card's interrupt handler even up to sending the packet
> > via another network card (at least in my case, when using route-to
> > targets,
Okay,
i figured out the includes, now it runs and seg faults:
root@fbsd1:~/netmap # ./n
Starting...
em0 registered...
sysctl passed
mem mapped...
nifp mapped...32766
rx ring def...
rx ring start...
Segmentation fault (core dumped)
root@fbsd1:~/netmap #
so apparently it faults at the initializatio
If it contends on the global pf lock, you're short of luck.
There may be some hack to enable in sysctl that defers part of the
packet processing into a taskqueue, but I dont' know if that's for
general IP processing or just socket iO processing. One of the network
stack peeps will know.
ADrian
... please ask the pfsense guys to either migrate to -9, or backport
the -head pf (with the locking fixes!) to -8 for that.
Otherwise you're very likely going to be wasting time on something you
can't really push that much harder.
I can ask for that (and will soon, likely), but to play with my
... please ask the pfsense guys to either migrate to -9, or backport
the -head pf (with the locking fixes!) to -8 for that.
Otherwise you're very likely going to be wasting time on something you
can't really push that much harder.
ADrian
On 25 April 2013 11:24, Erich Weiler wrote:
>> As far a
On 25 April 2013 02:28, Andre Oppermann wrote:
> Again one has to be really careful drawing any firm conclusions from this
> as it was measured on a Pentium4 and UP kernel (GENERIC would add WITNESS
> and INVARIANT overhead as well).
>
> The Pentium4 is about the worst micro-architecture when it
As far as I understand, processing of packets by pf takes place in receiving
network card's interrupt handler even up to sending the packet via another
network card (at least in my case, when using route-to targets, which make
routing inside pf).
That's interesting. So even though pf is giant l
On Wed, Apr 24, 2013 at 11:50 AM, Randall Stewart wrote:
> All
>
> Ok I fixed it ;-)
>
> Its in SVN r249848.
>
> I will see about getting it to 9 stable, 8 stable and maybe even
> 8.4 if RE will let me ;-)
>
Great work. Thanks so much. I was afraid this would linger forever!
> R
> On Apr 23, 201
Synopsis: Kernel panic: general protection fault in tcp_do_segment
Responsible-Changed-From-To: freebsd-amd64->freebsd-net
Responsible-Changed-By: pluknet
Responsible-Changed-When: Thu Apr 25 15:34:45 UTC 2013
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cg
nice work!
On 4/24/13, Olivier Cochard-Labbé wrote:
> Hi all,
>
> here is the result of my simple-and-dummy bench script regarding
> forwarding/ipfw/pf performance evolution on -current on a single-core
> server with one flow only.
> It's the result of more than 810 bench tests (including reboot
On 25.04.2013 07:40, Olivier Cochard-Labbé wrote:
On Wed, Apr 24, 2013 at 1:46 PM, Sami Halabi wrote:
3. there some point of improved performance (without fw) that went down
again somewhere before Clang got prod.
Found it !
It's commit 242402: "Rework the known mutexes..."
Again one has to
14 matches
Mail list logo
