-
Notifications
You must be signed in to change notification settings - Fork 579
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
Add vagrant VM support and XDP_USE_NEED_WAKEUP for advanced03 #70
base: master
Are you sure you want to change the base?
Conversation
This adds support for a Vagrant configuration that will build a VM running fedora29, with the latest bpf-next kernel. In addition, it will install and build the xdp-tutorials. Signed-off-by: Eelco Chaudron <[email protected]>
Adding this will give improved performance. In my setup, it goes from 6,428kpps to 6,661kpps for 128 bytes packets with the IPv6 ping packets replier (assignment 3). Signed-off-by: Eelco Chaudron <[email protected]>
Why fedora 29 instead of 30? Also, what would it take to turn this into
a test runnable from CI? We'd probably need a 'make selftest' kind of
target, but what else?
|
I tried Fedora30 but was giving me some odd errors on kernel install. Rather than spending too much time troubleshooting, I reverted to 29 which I know to be working.
Good question, I have no real experience with CI integration with Vagrant (from GitHub). |
I'll admit upfront: I have zero experience with "vagrant". Could you explain what is the advantage of using vagrant? Is this only to get a VM installed? I do love the idea of adding make target for: 'make selftests' |
Vagrant just installs a VM from a base image. This is useful if you want to test your code in a clean environment. If you have the latest includes copied, for example, the build will not fail. It also helps for people willing to try out the tutorial but don't want to mess with the kernel on their machine. |
Eelco Chaudron <[email protected]> writes:
> Could you explain what is the advantage of using vagrant?
Vagrant just installs a VM from a base image. This is useful if you
want to test your code in a clean environment. If you have the latest
includes copied, for example, the build will not fail.
Does it also support running the VM and executing a command inside it?
That is basically what we need to hook this up to CI...
|
Yes you can, for example:
|
Eelco Chaudron <[email protected]> writes:
> Does it also support running the VM and executing a command inside it? That is basically what we need to hook this up to CI...
Yes you can, for example:
```
vagrant ssh -c "cd xdp-turorial/advanced03-AF_XDP && make"
```
Right, so I tried actually running this, and it seems the vagrant plugin
installer is somewhat broken:
vagrant plugin install vagrant-reload
Installing the 'vagrant-reload' plugin. This can take a few minutes...
Fetching vagrant-reload-0.0.1.gem
Fetching formatador-0.2.5.gem
Fetching excon-0.66.0.gem
Fetching mini_portile2-2.4.0.gem
Fetching nokogiri-1.10.4.gem
Building native extensions. This could take a while...
Fetching fog-xml-0.1.3.gem
Fetching fog-json-1.2.0.gem
Traceback (most recent call last):
21: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/bin/vagrant:182:in `<main>'
20: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/environment.rb:290:in `cli'
19: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/cli.rb:66:in `execute'
18: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/plugins/commands/plugin/command/root.rb:66:in `execute'
17: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/plugins/commands/plugin/command/install.rb:69:in `execute'
16: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/plugins/commands/plugin/command/install.rb:69:in `each'
15: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/plugins/commands/plugin/command/install.rb:70:in `block in execute'
14: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/plugins/commands/plugin/command/base.rb:14:in `action'
13: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/action/runner.rb:102:in `run'
12: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/util/busy.rb:19:in `busy'
11: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/action/runner.rb:102:in `block in run'
10: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/action/builder.rb:116:in `call'
9: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/action/warden.rb:50:in `call'
8: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
7: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/action/warden.rb:50:in `call'
6: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/plugins/commands/plugin/action/install_gem.rb:30:in `call'
5: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/plugin/manager.rb:167:in `install_plugin'
4: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/bundler.rb:242:in `clean'
3: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/bundler.rb:242:in `each'
2: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.5/lib/vagrant/bundler.rb:251:in `block in clean'
1: from /usr/lib/ruby/2.6.0/rubygems/uninstaller.rb:162:in `uninstall_gem'
/usr/lib/ruby/2.6.0/rubygems/uninstaller.rb:264:in `remove': uninitialized constant Gem::RDoc (NameError)
|
What distro are you using, works on RHEL7. Some distributions have the vagrant modules as packages. |
Eelco Chaudron <[email protected]> writes:
What distro are you using, works on RHEL7. Some distributions have the
vagrant modules as packages.
I'm on Arch, which doesn't have the reload package, sadly... :/
|
@tohojo any reason for not merging this besides your distro having issues with vagrant? Not showing this on RHEL/Fedora. |
Add some basic version checking support to warn if a kernel version is not supporting AF_XDP. Signed-off-by: Eelco Chaudron <[email protected]>
This fixes execution failure when trying to load the custom XDP program with the tutorial and kernels < 5.3. Fixes #65 Signed-off-by: Eelco Chaudron <[email protected]>
Eelco Chaudron <[email protected]> writes:
@tohojo any reason for not merging this besides your distro having
issues with vagrant? Not showing this on RHEL/Fedora.
Hmm, not really, other than the fact that I couldn't really test it ;)
I'll give it another shot and see if I can't persuade the Vagrant plugin
installer to do its thing...
|
No dice; the Arch packaging for Vagrant plugins appears to be completely broken, and I can't get the vagrant plugin installer itself to do anything other than spit out errors. Can you make this work without the 'reload' plugin? |
I need to restart the machine after the kernel build, did not find a way to do this without a plugin. |
Eelco Chaudron <[email protected]> writes:
> Can you make this work without the 'reload' plugin?
I need to restart the machine after the kernel build, did not find a
way to do this without a plugin.
Why can't the kernel build not just execute a 'reboot' inside the vm?
|
As vagrant is doing the provisioning, just calling reboot will fail the provisioning step. |
Eelco Chaudron <[email protected]> writes:
> Why can't the kernel build not just execute a 'reboot' inside the vm?
As vagrant is doing the provisioning, just calling reboot will fail
the provisioning step.
Hmm, bugger.
Well, I guess I'll either have to find a Fedora or Debian install to try
this out on, or we'll just have to merge it without independent testing.
@netoptimizer, have you tried running vagrant script?
|
@@ -18,6 +19,17 @@ struct bpf_map_def SEC("maps") xdp_stats_map = { | |||
.max_entries = 64, | |||
}; | |||
|
|||
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,3,0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not the right approach to check against a kernel version.
(Because distros will backport changes)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know, but due to the lack of any run-time checks, what would you suggest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The configure script just sets some variables; so we can do that in the top-level and only react to them in advanced03. I've been meaning to port over some of the build stuff I did in xdp-tools to this repo anyway, so this sounds like a way forward :)
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,3,0) | ||
|
||
/* Kernel version before 5.3 needed an additional map */ | ||
struct bpf_map_def SEC("maps") qidconf_map = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this map referred to anywhere; how is it actually used on those old kernels?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think this is part of the older libbpf installing int
vagrant: add vagrant support to build latest bpf-next in VM
advanced03: add support for the XDP_USE_NEED_WAKEUP API