-
Notifications
You must be signed in to change notification settings - Fork 536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
patched OVS with ports other than vale created ports #266
Comments
Just to understand, are you using the patch at "utils/switch-modules/ovs-datapath/0001-datapath-Add-support-for-netmap-VALE.patch" ? |
@vmaffione yes, actually it is slightly modified by @micchie to support OVS 2.6.0, but I assume it shouldn't be that different |
Hi, The patch for OVS 2.6.1 has been published here https://github.com/luigirizzo/netmap/blob/master/utils/switch-modules/ovs-2.6.1/0001-datapath-netmap-VALE-support.patch . For the second question: yes, it is not possible to use two VALE switches with OVS on the same host, and it is a limitation of the current patch. This is actually more a problem of OVS, since afaik in the openvswitch kernel module there is no abstraction for the "bridge" object. This means that all the OVS bridges and ports you create share the same "datapath" object in kernelspace. As a consequence, there is no an easy way to tell (in kernel space) what OVS bridge a port is part of. |
@vmaffione when OVS is built with the new patch, the generated openvswitch.ko file in ovs/datapath/linux/ does not depend on netmap. Is it this expected? The old patch files used to build openvswitch.ko that depends on netmap |
@vmaffione the build process says "netmap_attach, netmap_detach, netmap_bdg_ctl undefined", thus the built ovs module does not depend on netmap. When inserted, invalid parameter error is reported. |
The patch fo 2.6.1 works fine to me. Are you using 2.4.0 or 2.6.1? |
I am using 2.6.1. Both OVS and netmap are the latest. What linux kernel and system are you using?
…On Jan 9, 2017, 12:43 PM -0500, Vincenzo Maffione ***@***.***>, wrote:
The patch fo 2.6.1 works fine to me. Are you using 2.4.0 or 2.6.1?
Of course openvswitch.ko must depend on netmap.ko
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I'm using linux 4.8.13 on archlinux. But this should not be important. Have you used the --with-netmap switch to point at the netmap sources? Are you sure you have applied the patch to the 2.6.1 tar.gz from the ovs website, or the v2.6.1 tag on the ovs github repo? |
I used the —with-netmap option, along with the —with-linux option. I applied it to the v2.6.1 tag on the GitHub repo.
…On Jan 9, 2017, 3:30 PM -0500, Vincenzo Maffione ***@***.***>, wrote:
I'm using linux 4.8.13 on archlinux. But this should not be important. Have you used the --with-netmap switch to point at the netmap sources? Are you sure you have applied the patch to the 2.6.1 tar.gz from the ovs website, or the v2.6.1 tag on the ovs github repo?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Have you installed netmap first and then installed openvswitch modules with ´´´´ make modules_install´´´´ Yours may be a depmod problem. You can also try to run depmod -a manually. |
Yes I installed netmap first. The problem occurred before installing openvswitch modules. The built openvswitch.ko modules does not depend on netmap. netmap_attach(), netmap_detach() methods are not found. Could it be that some netmap files are not installed properly on the system?
…On Jan 9, 2017, 3:54 PM -0500, Vincenzo Maffione ***@***.***>, wrote:
Have you installed netmap first and then installed openvswitch modules with
´´´´
make modules_install
´´´´
Yours may be a depmod problem. You can also try to run depmod -a manually.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
No. Attach and detach functions are defined in netmap_kern.h, which is not exported for now. So if you get an undefined reference error it means that either your --with-netmap path is wrong or that you are compiling netmap and ovs against two different kernel build infrastructures (you typically wantto.use se /lib/modules/´uname -r´/build for noth) |
@vmaffione I tried again, this time I make sure the same kernel build is used, but still can't generate the correct ovs module. The patch @micchie gave me months ago works, but his patch needs some fix for the latest netmap build. (I will email you his patch just for reference, maybe you could find his patch useful). |
I think the problem is that you are running the netmap ./configure (and
make) from inside the LINUX directory. Try to run them from the root of the
netmap repository, I.e. a level up.
Il 10 gen 2017 5:22 AM, "Yikai" <[email protected]> ha scritto:
@vmaffione <https://github.com/vmaffione> I tried again, this time I make
sure the same kernel build is used, but still can't generate the correct
ovs module. The patch @micchie <https://github.com/micchie> gave me months
ago works, but his patch needs some fix for the latest netmap build. (I
will email you his patch just for reference, maybe you could find his patch
useful).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#266 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEsSwWvhQFdtVHWwEJTdiGWNMjscsKPCks5rQweWgaJpZM4LY0EY>
.
|
@vmaffione now it works! I see that this patched version of OVS still can't work with mininet(it is stuck at starting switches stage), but I believe mininet is using veth pairs to connect hosts. Is there anything I can do to make mininet work? I have already loaded the netmap version of veth module. |
For sure you need to fetch the latest code to get a bug-fix for veth that just went in. You can attach veth interfaces to vale switches in general, this works ok. It works ok also in conjuction with OVS patched with netmap, you can use veth interfaces similarly to how you use persistent VALE ports. I've no idea why mininet does not work, it can simply be that the OVS patch is very experimental and incomplete. One of the problems is that broadcast does not work properly if you create more OVS bridges. A single datapath (in this case a VALE switch) is used to implement all the bridges, so the bridges are not isolated. |
I built the latest netmap and loaded both netmap.ko and veth.ko, and I created a simple mininet topology with the command mn, and the process is stuck at creating the switches, dmesg gives me the following errors. If I don't load veth.ko, the topology can be created, but h1 cannot ping h2. [12429.730416] (null): netmap queues/slots: TX 1/1024, RX 1/1024 |
Yes, the OVS patch is experimental, you need to debug it. Some pieces of advice:
|
My patched OVS works great with ports created with vale-ctl, but when I tried to attach other ports to the OVS bridge(the physical interfaces or the interfaces within VM), it failed. I got the "failed to add port XX, invalid argument" error.
I am trying to figure out if this is my problem or the inner limitation of the current patch. When I switch back to the original OVS I can attach whatever interface I want.
PS. just try to make sure I understand correctly, it is impossible to run OVS on two vale switches on the same host right? Coz every bridge I create will automatically be attached to vale0.
The text was updated successfully, but these errors were encountered: