Sorry beforehand if this question is trivial or even if the answer is the question.
Our devices have an application that employees DPDK to use its NICs.
As part of the device setup some init done, part of it is settings kernel variables net.ipv4.tcp_keepalive_intvl, tcp_max_syn_backlog, net.ipv4.conf.all.log_martians and etc
Do these kind of variables have any affect our ports under DPDK control?
Probably not, as DPDK is user space NICs, but I am not confident enough to assert it
As long as you have NIC which are listed in driver/net/ there are not much PMD devices which rely net.ipv4 other than TAP/TUN. So if it is physical NIC one would not be affected.
[EDIT-1]
only Physcial NIC with userspace PMD (not tap representations) can be guaranteed to be not be affected like e1000, ixgbe, i40e, ice, fm10k etc are not affected. PMD like AF_PACKET/AF_XDP are also not affected while TAP/PCAP goes through linux stack
Related
I would like to setup a dpdk env then i can do packet generation and packet capture in one VM. Is this even possible ? If it is, may i ask what will the (port layout etc) setup look like in details ?
I have tried creating 2 dpdk compatible ports in one VM, and did pktgen on one port, doing packet capturing on the other. But it doesn't work. Note, while doing pktgen, i already specify the dst mac address is the mac addr of the other port which the packet capturing app is sniffing.
It seems I either wire these 2 ports together physically or create a loopback for these 2 ports which i didn't know how.
Thanks !
It should be possible. Please note that "it doesn't work" doesn't quite describe your problem, so i'll have to go off my assumptions here.
Two instances of DPDK (e.g. pktgen and, say, l3fwd) should be able to coexist on a single VM without any problems, provided that you run both with different prefixes, and use the PCI white/blacklist to ensure that no port is used in more than one instance of DPDK.
So, assuming you have your ports at 08:00.0 and 09:00.0, the following might be the command-line:
./dpdk_app1 -w 08:00.0 --file-prefix=app1 # use only 08:00.0, use prefix app1
./dpdk_app2 -w 09:00.0 --file-prefix=app2 # use only 09:00.0, use prefix app2
If you're not using fairly recent (18.05+) versions of DPDK, you will also have to limit amount of memory each application will use, as by default older versions of DPDK will take over your entire hugepage memory. This is not an issue for DPDK versions 18.05+ so if you're using that, you can disregard this paragraph.
Now, to your question of logistics of how to run two ports - this is left up to you. You can connect two ports back-to-back if you are using physical NICs (either using PCI pass-through, or using Virtual Functions). This is (IMO) the easiest way, however bear in mind that Virtual Functions's port MAC address needs to match the one defined by the host - otherwise the traffic will not be steered to/from your Virtual Functions.
I have never tried this, but it is a reasonable assumption to make that sending traffic VF to VF directly should also work, provided you have set up your MAC addresses correctly. There are references to a DTS test[1] which does exactly that (only using two VM's instead of one, which i don't think would make any difference), so it should be possible.
You can also use entirely virtual ports, and use one of our software drivers (e.g. tun[2] or pcap drivers[3]) - it won't be performant, but it'll do the job.
[1] https://doc.dpdk.org/dts/test_plans/vf_to_vf_nic_bridge_test_plan.html
[2] https://doc.dpdk.org/guides/nics/tap.html
[3] https://doc.dpdk.org/guides/nics/pcap_ring.html
I'm trying to use Psychopy to trigger a second machine's data collection. I could use an I/O card, but I wondered how difficult it would be to use the NICs in Ad-Hoc mode?
Thank you
We are currently communicating with an eye link 2 running our experiment on one machine and the eye link software on another. In some tests of the mirametrix eye tracker we also used some variations of virtual and real machines talking to one another (as an aside, we never quite got the performance from the mirametrix that we needed).
We mention some of the tools we used here: https://brittlab.uwaterloo.ca/research-tips/
If you have a network card in each machine you could just connect them with an ethernet cable and set up tcp/ip to let the programs on the two machines talk to each other. If one machine needs to also talk to the outside world you could add a second network card (or if a laptop just buy a cheap usb wireless).
With more specifics about what you are trying to achieve others may be able to give you more specific feedback.
We're using libusb v1.0.9.0 in C++ code (with a Java front end). We're testing it on multiple versions of Windows and multiple machines for various USB 2.0/3.0 controllers, and we've found a couple of very bad problems.
On Windows 7, it can't see any ports on an "Intel USB 3.0 Extensible Host Controller" platform.
On Windows Server 2008, it can't see certain ports on both the USB 2.0 and 3.0 controllers. Some ports on the 2.0 hub work, and some ports on the 3.0 hub work, but other ports are invisible to the same device, to any device.
The first one might be just a specific controller idiosyncrasy that will be supported soon, but the second one really worries us. Is this kind of behavior common? How do we fix it?
We're using libusb_get_device_list() or libusb_open_device_with_vid_pid().
I had some trouble concerning certain USB 3.0 ports as well, even though it was maybe a little different to your situation. So I am not quite sure if I can help you out, I believe it's more related to a hardware-issue. But keep in mind the following facts:
USB 3.0 hardware is not yet well established (still under development) - some ports are loosing their functionality over the time, especially these quite cheap ones (built-in ports on mainboards with an Intel chipset). Because the current provided over USB 3.0 and the data rate is much higher than USB 2.0, it's not a miracle that these ports made of cheap wire break easily.
Even using a different cable makes a difference, not speaking of hubs - they seem to be still prototypes, at least the ones I used.
Keep looking regularly for the latest drivers of your xHCI. There are often nasty bugs fixed within.
Last, but not least, vary the size of packets sending to your xHCI. Actually, the preferred size is 64 KB, so split up your data in blocks of this size. This is related to the problem of the interrupts which are caused by huge packets. To some xHCIs this is already the reason to surrender (especially if you are running under USB 2.0!).
All in all, the behaviour of different xHCIs (Renesas, Intel, ..) differs quite a lot. It is mostly annoying because the reason is not obvious at all.
A last suggestion: Try tools like the USBlyzer. The last option would be something like Voyager M3i (protocol analyzer), if you are willing to spent about US$30,000 or so..
Hello i have an application built some times ago in C++.
It is used to control an appliance via serial port.
I remember the guy that developed it saying that his software is directly accessing the serial port (directly accessing the memory).
Since PCs with serial ports are becoming rare these days, would the software still directly access the serial port if i used a PCI extension serial port?
Thanks
That depends a bit on how much backward-compatible driver support your PCIe serial port has.
If it provides direct I/O-space mapping of a (possibly virtual) 16550 UART's registers, you will need to change the "base address" in the software but then it might work. If the drivers do not, then it's not going to work.
The first four standard serial ports have the following base addresses and interrupts associated with them:
| base IRQ
-----------------
COM1 | 0x3f8 IRQ4
COM2 | 0x2f8 IRQ3
COM3 | 0x3e8 n/a
COM4 | 0x2e8 n/a
The software should probably be rewritten to use more high-level access to the port.
I believe that the vast majority of local bus serial port cards emulate a 16x50 RS-232 UART. Unless you intend to use some special card, such as those expensive multiport cards used for managing modem banks, it would probably be fine.
USB/RS-232 converters are a different story altogether - in general they will not work with software that accesses the serial port directly, as their driver only provides access via the OS serial port subsystem. Even if their driver somehow manages to emulate a proper local bus UART, those converters often have different behavior w.r.t. signal timing that might lead to issues with software that does unusual things with the serial port. For example, I have had issues with attaching IR remote control receivers to some USB/RS-232 converters. Using a converter that supports USB 2.0 helps somewhat, but it is still far from the real thing.
You should also keep in mind that if your application is designed for an older OS, newer versions of that operating system might not allow direct access to serial ports anymore.
If all else fails, you might still be able to improve the situation by using a virtual machine. For example, VirtualBox allows the guest OS to access the host serial ports, emulating a 16550A UART. This might allow you to work around a driver or an OS that does not support or allow direct access to a serial port.
I searched around i found some PCI cards that map their serial ports to the memory.
I will try one of those.
Thank you all.
I have another solution.
PCs are coming with mostly usb ports.
so you can use any usb to serial port converter. it is very cheap and works fine.
I'm trying to make my program robust against network disconnections. Right now, if I disable ethernet network from OS (I'm over Ubuntu 11.10, but I guess that should not matter), my sockets recover once the network is enabled again and everything goes all right.
Since now I have supposed this test was the same as unpluging the ethernet cable. But it is not, since my program is suddenly terminating when doing this.
I want to know what's the difference between these two scenarios, and how to detect both of them. I'm using QTcpSockets from Qt and C++.
Also, when wifi is no longer detected, I guess it's equal to unplugging ethernet cable, while disabling it at the OS is equivalent to disable ethernet network. Am I right?
When the driver is enables, it means there is a program running at the OS kennel that manages different scenarios. For example, on cable disconnect, there is a link drop. And entering to low power mode.
When disabling the driver either there is a firmware on your device that could manage the device on, or there device will be off.