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 <[email protected]>: > Some comments inline: > > 2017-06-16 14:13 GMT+02:00 Jordan Caraballo <[email protected]>: > >> 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 by >> the log from the script, but the issue was still present. >> > > If > > # ./bridge ifname1 ifname2 > > doesn't work it means there is some problem with the driver the interfaces > are using. Default burst size used by "bridge" is already 1024. > You may try to repeat this experiment after setting "sysctl > dev.netmap.admode=2", to use the emulated mode, that is the legacy driver > (of course performance would be limited, but at least you check > functionality). > Check netmap(4) for more info. > > >> >> Second Attempt: Tried to combine vale-ctl and bridge by: >> # ./vale -h vale0:vcxl0 >> # ./vale -h vale0:vcxl1 >> # ./bridge vale0:1 vale0:3 > > >> There was no error, however, traffic did not flow at the time of >> shooting packets to the interfaces. >> > > What did you mean to do here? This setup creates a forwarding loop > involving the VALE switch "vale0" and the userspace hub implemented by > "bridge". > I'm not surprised that you see nothing.. > > >> >> Third Attempt: By following this email >> threadhttps://lists.openinfosecfoundation.org/pipermail/ >> oisf-users/2015-October/005310.html; >> we ran: >> # ./vale-ctl -n b0 >> # ./vale-ctl -n b1 >> # ./vale-ctl -a vale0:b0 >> # ./vale-ctl -a vale0:vcxl0 >> # ./vale-ctl -a vale1:b1 >> # ./vale-ctl -a vale1:vcxl1 >> # ./bridge -i netmap:vcxl0 -i netmap:vcxl1 >> >> Same result as before, no errors, yet no traffic in the interfaces. >> >> > This should throw errors, as you are first attaching vcxl0 to a VALE > switch, and then opening vclx0 in netmap mode with the bridge program: > netmap forbids you to do that, because when an interface is attached to a > VALE switch it is "busy", and cannot be opened again from another netmap > application (like bridge). > Same reasoning for vcxl1. > > Have you tried with the basic TX/RX tests first, without involving VALE? > > # pkt-gen -i netmap:vcxl0 -f tx > # pkt-gen -i netmap:vcxl0 -f rx > > > Regards, > Vincenzo > > >> Any feedback or advice on why traffic is not flowing? >> >> We would like to note that throwing packets to the vcxl interfaces >> without any netmap aware application ranges from 1.1M to 1.2M pps. >> >> Is this supposed to happen? (We consider that still, the number is quite >> low) >> >> - Jordan >> >> >> 2017-06-15 17:15 GMT-04:00 Navdeep Parhar <[email protected]>: >> >> > On 06/14/2017 10:42, Olivier Cochard-Labbé wrote: >> > >> >> On Wed, Jun 14, 2017 at 7:36 PM, Navdeep Parhar <[email protected] >> >> <mailto:[email protected]>> 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. >> >> >> >> >> > Fixed in r319986. >> > >> > >> > _______________________________________________ >> > [email protected] mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "[email protected]" >> > >> >> >> >> -- >> Jordan >> _______________________________________________ >> [email protected] mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "[email protected]" >> > > > > -- > Vincenzo Maffione > -- Vincenzo Maffione _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
