On 5/5/15 10:46 PM, Barney Cordoba wrote:
Are you NOT SHARP ENOUGH to understand that my proposal DOESN'T USE
THE NETWORK STACK? OMFG
Barney, your proposal is that we provide a framework to allow network
IP stack bypass in the case of special processing.
that framework still needs to be hooked
Are you NOT SHARP ENOUGH to understand that my proposal DOESN'T USE THE NETWORK
STACK? OMFG
Julien, perhaps if people weren't so hostile towards commercial companies
providing ideas for alternative ways of doing things you'd get more input and
more help. Why would I want to help these people?
BC
> On May 4, 2015, at 10:07 PM, Julian Elischer wrote:
>
> Jim, and Barney. I hate to sound like a broken record, but we really need
> interested people in the network stack.
> The people who make the decisions about this are the people who stand up and
> say "I have a few hours I can spend on
> On May 4, 2015, at 11:53 AM, Barney Cordoba wrote:
>
> I'll assume you're just not that clear on specific implementation.
Thank you for your assumption. Have you noticed that you tend to argue by
insinuating that the other party is stupid, or at best, responsible for “hacks”?
> Hooking dir
I'll assume you're just not that clear on specific implementation. Hooking
directly into if_input() bypasses all of the "cruft". It basically uses the
driver "as-is", so any driver can be used and it will be as good as the driver.
The bloat starts in if_ethersubr.c, which is easily completely av
While it is a true statement that, "You can do anything in the kernel that you
can do in user space.”, it is not a helpful statement. Yes, the kernel is just
a program.
In a similar way, “You can just pop it into any kernel and it works.” is also
not helpful. It works, but it doesn’t work wel
On Mon, Nov 10, 2014 at 12:09 PM, Evandro Nunes
wrote:
> On Sun, Nov 9, 2014 at 9:23 PM, Luigi Rizzo wrote:
>
>>
>>
>> On Sun, Nov 9, 2014 at 1:17 PM, Evandro Nunes
>> wrote:
>>
>>> professor luigi
>>>
>>> where can I find the code for netmap-fwd you mentioned on usenix paper?
>>>
>>>
>> that
On Sun, Nov 9, 2014 at 9:23 PM, Luigi Rizzo wrote:
>
>
> On Sun, Nov 9, 2014 at 1:17 PM, Evandro Nunes
> wrote:
>
>> professor luigi
>>
>> where can I find the code for netmap-fwd you mentioned on usenix paper?
>>
>>
> that has been renamed to bridge.c
>
> cheers
> luigi
>
so it does not actua
On Sun, Nov 9, 2014 at 1:17 PM, Evandro Nunes
wrote:
> professor luigi
>
> where can I find the code for netmap-fwd you mentioned on usenix paper?
>
>
that has been renamed to bridge.c
cheers
luigi
>
> ** https://www.usenix.org/system/files/conference/atc12/atc12-final186.pdf
>
> On Sun, No
professor luigi
where can I find the code for netmap-fwd you mentioned on usenix paper?
** https://www.usenix.org/system/files/conference/atc12/atc12-final186.pdf
On Sun, Nov 9, 2014 at 5:31 PM, Evandro Nunes
wrote:
> hello again patrick
>
> On Sun, Nov 9, 2014 at 12:54 AM, Patrick Tracanelli
hello again patrick
On Sun, Nov 9, 2014 at 12:54 AM, Patrick Tracanelli <
eks...@freebsdbrasil.com.br> wrote:
> > (Machine-A)<-->Machine-B<--->(MachineC)
> >
> > Machine-A:
> > em0 172.16.251.3/24
> >
> > Machine-B:
> > em1: 172.16.251.1/24
> > em2: 172.16.252.1/24
> > 10.0-STABLE w/ latest netma
Dear Evandro Nunes,
You are just not reading. Ealy I mentioned the netmap:port syntax because your
previous syntax were turning out on errors opening the port that you just didnt
pay attention on ./kipfw's output.
Now you just didnt read what Mahanaz Tabeli wrote ;-) Please fo *read* below!!
:
On Sat, Nov 8, 2014 at 5:26 AM, Mahnaz Talebi wrote:
> Hi Evandro.
> I've tested netmap-ipfw on real NICs.
> Use "
>
> ./kipfw -i netmap:em0 -i netmap:em1
> " to run netmap-ipfw on em0 and em1. ipfw works as a bridge and copy
> incoming packets to em0 to em1 if they pass defined rules (and vice
Hi Evandro.
I've tested netmap-ipfw on real NICs.
Use "
./kipfw -i netmap:em0 -i netmap:em1
" to run netmap-ipfw on em0 and em1. ipfw works as a bridge and copy
incoming packets to em0 to em1 if they pass defined rules (and vice versa,
from em1 to em0).
If you still have problem with ipfw-netmap,
On Fri, Nov 7, 2014 at 4:08 PM, Luigi Rizzo wrote:
>
>
> On Fri, Nov 7, 2014 at 5:02 AM, Evandro Nunes
> wrote:
>
>> On Thu, Nov 6, 2014 at 9:24 PM, Luigi Rizzo wrote:
>>
>>> The code on code.google.com/p/netmap-ipfw/ works well for me
>>> on physical interfaces.
>>>
>>> For using the nics many
On Fri, Nov 7, 2014 at 5:02 AM, Evandro Nunes
wrote:
> On Thu, Nov 6, 2014 at 9:24 PM, Luigi Rizzo wrote:
>
>> The code on code.google.com/p/netmap-ipfw/ works well for me
>> on physical interfaces.
>>
>> For using the nics many of your examples show that you are not using the
>> various program
On Thu, Nov 6, 2014 at 9:24 PM, Luigi Rizzo wrote:
> The code on code.google.com/p/netmap-ipfw/ works well for me
> on physical interfaces.
>
> For using the nics many of your examples show that you are not using the
> various programs correctly. There is clearly a
> mismatch between what this co
The code on code.google.com/p/netmap-ipfw/ works well for me
on physical interfaces.
For using the nics many of your examples show that you are not using the
various programs correctly. There is clearly a
mismatch between what this code does and your expectations,
and there isn't much i can do to
On Wed, Nov 5, 2014 at 10:40 PM, Evandro Nunes
wrote:
> On Wed, Nov 5, 2014 at 8:44 PM, Patrick Tracanelli <
> eks...@freebsdbrasil.com.br> wrote:
>
>> Hey, what you are doing wrong is much more simple than you expect.
>>
>> > # ./kipfw em1 em2 > & /tmp/kipfw.log &
>> > [1] 66583
>>
>> Just run .
On Wed, Nov 5, 2014 at 8:44 PM, Patrick Tracanelli <
eks...@freebsdbrasil.com.br> wrote:
> Hey, what you are doing wrong is much more simple than you expect.
>
> > # ./kipfw em1 em2 > & /tmp/kipfw.log &
> > [1] 66583
>
> Just run ./kipfw netmap:em1 netmap:em2 and this will probably work.
>
> Pleas
Hey, what you are doing wrong is much more simple than you expect.
> # ./kipfw em1 em2 > & /tmp/kipfw.log &
> [1] 66583
Just run ./kipfw netmap:em1 netmap:em2 and this will probably work.
Please remember to redirect kipfw output to somewhere you are not reading only
*after* you are sure the out
dear luigi
sadly it still did not work, I have the scenario set, please see below:
On Tue, Nov 4, 2014 at 8:12 PM, Luigi Rizzo wrote:
> On Tue, Nov 04, 2014 at 05:44:43PM -0200, Evandro Nunes wrote:
> > On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote:
> ...
> > >> i gues I am missing a piece
On Tue, Nov 4, 2014 at 8:12 PM, Luigi Rizzo wrote:
> On Tue, Nov 04, 2014 at 05:44:43PM -0200, Evandro Nunes wrote:
> > On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote:
> ...
> > >> i gues I am missing a piece of the architecture...
> > >>
> > >
> > > ???probably yes :)
> > >
> > > kipfw em1 e
On Tue, Nov 04, 2014 at 05:44:43PM -0200, Evandro Nunes wrote:
> On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote:
...
> >> i gues I am missing a piece of the architecture...
> >>
> >
> > ???probably yes :)
> >
> > kipfw em1 em2 connects the two interfaces to each other, keeping the
> > rest ???
On Tue, Nov 4, 2014 at 5:52 PM, Michal Buchtík wrote:
> Dne 4.11.2014 20:44, Evandro Nunes napsal(a):
>
>> # ifconfig "em2" | grep flags
>> em2: flags=28d02
>> metric 0 mtu 1500
>>
> Hi,
> interface is OACTIVE and down.
>
> Do you try "ifconfig em2 up" ?
>
hey Michal,
strange, both NICs are ad
Dne 4.11.2014 20:44, Evandro Nunes napsal(a):
# ifconfig "em2" | grep flags
em2: flags=28d02
metric 0 mtu 1500
Hi,
interface is OACTIVE and down.
Do you try "ifconfig em2 up" ?
Michal
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org
On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote:
>
>
> On Tue, Nov 4, 2014 at 11:09 AM, Evandro Nunes
> wrote:
>
>> so, running em1 and em2 only should work?
>>
>> because I have the same behavior:
>>
>> # ps wauxw | grep kipfw
>> root 61484 0.0 0.0 14648 1824 2 S 5:06PM
On Tue, Nov 4, 2014 at 11:09 AM, Evandro Nunes
wrote:
> so, running em1 and em2 only should work?
>
> because I have the same behavior:
>
> # ps wauxw | grep kipfw
> root 61484 0.0 0.0 14648 1824 2 S 5:06PM 0:02.95
> ./kipfw em1 em2
> root 61518 0.0 0.0 18804
so, running em1 and em2 only should work?
because I have the same behavior:
# ps wauxw | grep kipfw
root 61484 0.0 0.0 14648 1824 2 S 5:06PM 0:02.95
./kipfw em1 em2
root 61518 0.0 0.0 18804 1864 2 S+5:07PM 0:00.00
grep kipfw
# /usr/src/tools/too
the user space netmap-ipfw only supports two interfaces,
The hard problem in moving to 3+ interfaces is not much the code but
deciding where to send a packet once it has passed the filter.
Basically, passing things through the kernel stack is simple
but performance is going to be no better than
btw,
I am generating traffic via pkt-gen which I can see os received on the
other side:
# /usr/src/tools/tools/netmap/netmap-7e9e5e7602f5/examples/pkt-gen -i em1
-f tx -l 60 -d 172.16.250.10
643.417060 main [1649] interface is em1
643.417344 extract_ip_range [287] range is 10.0.0.1:0 to 10.0.0.1:
31 matches
Mail list logo
