Also, there is a more basic problem. The bridge program requires physical
interfaces to be specified with the "netmap:" prefix. For example:
# ./bridge netmap:ix0 netmap:em2# OK
# ./bridge ix0 em2 # WRONG
2017-06-16 14:47 GMT+02:00 Vincenzo Maffione
Some comments inline:
2017-06-16 14:13 GMT+02:00 Jordan Caraballo :
> Hi guys,
>
> We tried multiple attempts to implement netmap vale-ctl and bridge in
> chelsio vcxl* interfaces. The most interesting attempts, are mentioned
> below.
>
> First Attempt: Ran "./bridge
Hi guys,
We tried multiple attempts to implement netmap vale-ctl and bridge in
chelsio vcxl* interfaces. The most interesting attempts, are mentioned
below.
First Attempt: Ran "./bridge vcxl0 vcxl1"; but it would complain about
having a 0 burst size. Added "-b 1024" to the command as recommended
On 06/14/2017 10:42, Olivier Cochard-Labbé wrote:
On Wed, Jun 14, 2017 at 7:36 PM, Navdeep Parhar > wrote:
I think I fixed this a long time back. Have you tried recently? We
moved the netmap functionality to the vcxl interfaces and it
Responding to the thread as a whole: another alternative is the FLOWTABLE
kernel option. I added route and link-layer caching for endpoints (TCP and
UDP), which makes the FLOWTABLE option less useful (or undesirable) there,
but FLOWTABLE adds route caching for packet forwarding as well. I’d
Do you mean it works with one pkt-gen but panics when the second one is started?
On Wed, Jun 14, 2017 at 10:42 AM, Olivier Cochard-Labbé
wrote:
> On Wed, Jun 14, 2017 at 7:36 PM, Navdeep Parhar wrote:
>>
>>
>> I think I fixed this a long time back. Have
On Wed, Jun 14, 2017 at 7:36 PM, Navdeep Parhar wrote:
>
> I think I fixed this a long time back. Have you tried recently? We
> moved the netmap functionality to the vcxl interfaces and it should
> just work.
>
>
It stills panic with an -head build today.
On Wed, Jun 14, 2017 at 8:21 AM, Olivier Cochard-Labbé
wrote:
> On Wed, Jun 14, 2017 at 4:48 PM, John Jasen wrote:
>
>>
>> b) On the negative side, between the various releases, netmap appeared
>> to be unstable with the Chelsio cards -- sometimes
> On Jun 14, 2017, at 9:48 AM, John Jasen wrote:
>
> Our goal was to test whether or not FreeBSD currently is viable, as the
> operating system platform for high speed routers and firewalls, in the
> 40 to 100 GbE range.
We recently showed IPsec running at 36.32Gbps (8
Il 14 giu 2017 5:21 PM, "Olivier Cochard-Labbé" ha
scritto:
On Wed, Jun 14, 2017 at 4:48 PM, John Jasen wrote:
>
> b) On the negative side, between the various releases, netmap appeared
> to be unstable with the Chelsio cards -- sometimes supported,
On 6/14/2017 10:48 AM, John Jasen wrote:
> Our goal was to test whether or not FreeBSD currently is viable, as the
> operating system platform for high speed routers and firewalls, in the
> 40 to 100 GbE range.
>
> In our investigations, we tested 10.3, 11.0/-STABLE, -CURRENT, and a USB
> stick
On Wed, Jun 14, 2017 at 4:48 PM, John Jasen wrote:
>
> b) On the negative side, between the various releases, netmap appeared
> to be unstable with the Chelsio cards -- sometimes supported, sometimes
> broken. Also, we're still trying to figure out netmap utilities, such as
>
Hi,
To test netmap raw forwarding performance using just one core, use the
bridge program between two netmap supported NICs, like ix or ixl
# ./bridge ix0 ix1
You could implement your own multicore software router by extending the
bridge example to implement the protocols you need.
Vale-ctl
Our goal was to test whether or not FreeBSD currently is viable, as the
operating system platform for high speed routers and firewalls, in the
40 to 100 GbE range.
In our investigations, we tested 10.3, 11.0/-STABLE, -CURRENT, and a USB
stick from BSDRP using the FreeBSD routing improvements
14 matches
Mail list logo