-
Notifications
You must be signed in to change notification settings - Fork 297
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
using a real nic #1434
Comments
Might be that you need to make Linux release the NIC/pci resource first? Seems like Linux has already attached a driver. A If that doesn’t fix it, could you include the output of Another thing from the top of my head is to make sure the kernel is booted with As an aside: in case you didn’t see it, there is a L2 learning bridge app in |
Thanks ! This worked. Now I've done a setup where
Also @eugeneia I wanted to use the learning bridge but since I didn't really get how everything worked I first want to reimplement the sink and repeater application on real interface. |
The expected behaviour is that you shouldn’t have to do this and Snabb would just unbind it automatically. So I think we need to fix the underlying issue described in #1286 as @alexandergall mentioned (which includes a suggested approach IIUC). I think your problem is that I collected some hints before realizing this, maybe they are useful still:
This basically means that the NIC didn’t receive any packets, or at least it didn’t put any packets on its
In the latter case 40407 is the pid of the Snabb process. You can also query these while the process is running (even without while true do
engine.main({duration=10, report = {showlinks=true}})
end and leave the process running while debugging. One interesting field (beyond checking if there are any rx packets) is the status register. (In this case where there is no Also, you could run the intel_mp selftest on two ports connected to each other to make sure the NIC is functional. (Is
|
Ok so I changed my code to this : function run (parameters)
local c = config.new()
config.app(c, "learning", switch.Switch, parameters)
config.app(c, "nic2", intel_mp, {pciaddr="0000:04:00.0"})
config.link(c, "nic2.output -> learning.input")
engine.configure(c)
engine.main({duration=10, report = {showlinks=true}})
end And then ran it with this Still got zero packets, BUT as you guessed it, when looking at the stats I got this :
So the link is down. And obviously when I run the test they fail, here is what I get : For the iommu I don't khow how I can be sure it's not running.
Here as you can see the iommu seems off. And I also tried to add the |
You can restore device control to the kernel via If you added
if it was enabled. I’d double-check that the ports are cabled, maybe reboot for good luck. ;-) Just to mention it, you can also test your code on a single port of the NIC. I.e., if you can have two instances of the intel_mp driver on a port using VMDq and the NIC will switch packets between them, no cable required.
|
I suppose in this case it would be interesting to know how the tests failed exactly, like what’s the cause? Didn’t get a link up? Is there some sort of error message? Could you include the output of
in a gist? |
The log were too big so I've uploaded everything on my server : |
Hmm yeah I naively underestimated the amount of data that would produce. Either there is nothing suspicious in there or I can’t find it. Does using the NIC in VMDq mode (#1434 (comment)) work? If you are willing to give me access to the box I could try to debug this interactively when I find some time. My SSH pubkey is
Sorry for the frustrating first experience. :-/ |
Actually I don't know how I could check if anything works with VMDq. Could you provide some sort of main I could run ? Since I'm running these tests from my company computer I can't really give you any access to it sorry |
You can configure two intel_mp apps on a single port using vmdq. Check this out: #!snabb snsh
local intel_mp = require("apps.intel_mp.intel_mp")
local basic_apps = require("apps.basic.basic_apps")
local synth = require("apps.test.synth")
nic_pci = "01:00.0"
mac_vif1 = "52:00:00:00:00:01"
mac_vif2 = "52:00:00:00:00:02"
local c = config.new()
config.app(c, "vif1", intel_mp.Intel,
{pciaddr=nic_pci, vmdq=true, macaddr=mac_vif1})
config.app(c, "vif2", intel_mp.Intel,
{pciaddr=nic_pci, vmdq=true, macaddr=mac_vif2})
config.app(c, "source", synth.Synth, {src=mac_vif1, dst=mac_vif2})
config.app(c, "sink", basic_apps.Sink)
config.link(c, "source.output -> vif1.input")
config.link(c, "vif2.output -> sink.input")
engine.configure(c)
engine.main{duration=10}
engine.report_links() I saved this as
This will use the NIC but does not actually depend on the link (the packets are switched on the chip.) If this works for you we at least know the card works and its just the link up we are having issues with. |
Ok so I just changed the
Also I was wondering, is it normal to have this much huge page allocated ? |
Huge page allocation seems normal. It depends on the application but Snabb will initially fill the packet free list with hugepage/DMA memory and ~100 hugepages just for that is normal. What you are experiencing certainly looks like the IOMMU issue. I just checked back with the configuration we use in the lab and noticed the boot parameter we set is actually By the way, could you test if #1436 fixes your initial problem? |
Hello, Sorry I was working on something else. So I updated my boot parameters, now when run dmesg I got that :
The When I run the vmdq test I also get the same result :
I will test your fix in some minutes. |
Hello, I'm trying to understand how snabb works with real nic.
From what I've read I should use the
intel_mp
application, here is a dump ofsudo lshw -class network -businfo
:So by reading the documentation here http://snabbco.github.io/#intel-i210-i350-82599-ethernet-controller-apps-apps.intel_mp.intel_mp I guess I could run a program on either of theses interfaces :
eth5, eno1, enp4s0f0, enp4s0f1
.So I wrote a little program like that :
With the
switch.lua
being that :So my program should just print a message when it receive a packet and drop it.
But the thing is, when running this program I got this error :
I've tried to use a different pci_addr but it did not change anything.
The text was updated successfully, but these errors were encountered: