ethtool | A simple ethtool `` like '' library for GO

I have been debugging a linking error for specific target (android), for all other targets, build is successful.

Error is something like

I have build an UDP server with C++ and I have a couple questions about this.

Goal:

I have incomming TCP trafic and I need to sent this further as UDP trafic. My own UDP server then processes this UDP data. The size of the TCP packets can vary.

Details:

In my example I have a TCP packet that consists of a total of 2000 bytes (4 random bytes, 1995 'a' (0x61) bytes and the last byte being 'b' (0x62)).

My UDP server has a buffer (recvfrom buffer) with size larger then 2000 bytes. My MTU size is 1500 everywhere.

My server is receiving this packet correctly. In my UDP server I can see the received packet has a length of 2000 and if I check the last byte buffer[1999], it prints 'b' (0x62), which is correct. But if I open tcpdump -i eth0 I see only one UDP packet: 09:06:01.143207 IP 192.168.1.1.5472 > 192.168.1.2.9000: UDP, bad length 2004 > 1472. With the tcpdump -i eth0 -X command, I see the data of the packet, but only ~1472 bytes, which does not include the 'b' (0x62) byte.

The ethtool -k eth0 command prints udp-fragmentation-offload: off.

So my questions are:

1. Why do I only see one packet and not two (fragmented part 1 and 2)?
2. Why dont I see the 'b' (0x62) byte in the tcpdump?
3. In my C++ server, what buffer size is best to use? I have it now on 65535 because the incomming TCP packets can be any size.
4. What will happen if the size exceedes 65535 bytes, will I have to make an own fragmentation scheme before sending the TCP packet as UDP?

I have configured 1 master 2 workers. after installation successfully kubernetes. It is OK with worker1 joining cluster but I can not join worker2 to the cluster because kubelet service is not running. It seems like the kubelet isn't running or healthy

sudo kubectl get nodes:

NAME STATUS ROLES AGE VERSION
master1 Ready control-plane,master 23m v1.22.2
node1 NotReady 4m13s v1.22.2

I want to know why the kubelet service is not running.

Here kubelet logs.

I have deployed OpenStack and configured OVS-DPDK on compute nodes for high-performance networking. My workload is a general-purpose workload like running haproxy, mysql, apache, and XMPP etc.

When I did load-testing, I found performance is average and after 200kpps packet rate I noticed packet drops. I heard and read DPDK can handle millions of packets but in my case, it's not true. In guest, I am using virtio-net which processes packets in the kernel so I believe my bottleneck is my guest VM.

I don't have any guest-based DPDK application like testpmd etc. Does that mean OVS+DPDK isn't useful for my cloud? How do I take advantage of OVS+DPDK with a general-purpose workload?

We have our own loadtesting tool which generate Audio RTP traffic which is pure UDP based 150bytes packets and noticed after 200kpps audio quality go down and choppy. In short DPDK host hit high PMD cpu usage and loadtest showing bad audio quality. when i do same test with SRIOV based VM then performance is really really good.

While writing a simple DPDK packet generator I noticed some additional initialization steps that are required for reliable and successful packet transmission:

1. calling rte_eth_link_get() or rte_eth_timesync_enable() after rte_eth_dev_start()
2. waiting 2 seconds before sending the first packet with rte_eth_tx_burst()

So these steps are necessary when I use the ixgbe DPDK vfio driver with an Intel X553 NIC.

When I'm using the AF_PACKET DPDK driver, it works without those extra steps.

• Is this a bug or a feature?
• Is there a better way than waiting 2 seconds before the first send?
• Why is the wait required with the ixgbe driver? Is this a limitation of that NIC or the involved switch (Mikrotik CRS326 with Marvell chipset)?
• Is there a more idiomatic function to call than rte_eth_link_get() in order to complete the device initialization for transmission?
• Is there some way to keep the VFIO NIC initialized (while keeping its link up) to avoid re-initializing it over and over again during the usual edit/compile/test cycle? (i.e. to speed up that cycle ...)

Additional information: When I connect the NIC to a mirrored port (which is configured via Mikrotik's mirror-source/mirror-target ethernet switch settings) and the sleep(2) is removed then I see the first packet transmitted to the mirror target but not to the primary destination. Thus, it seems like the sleep is necessary to give the switch some time after the link is up (after the dpdk program start) to completely initialize its forwarding table or something like that?

Waiting just 1 second before the first transmission works less reliable, i.e. the packet reaches the receiver only every odd time.

My device/port initialization procedure implements the following setup sequence:

Wikipedia says:

Wake-on-LAN (WoL) is an Ethernet or Token Ring computer networking standard that allows a computer to be turned on or awakened by a network message.

But, in another section:

Responding to the magic packet ... Most WoL hardware functionally is typically blocked by default and needs to be enabled in using the system BIOS. Further configuration from the OS is required in some cases, for example via the Device Manager network card properties on Windows operating systems.

Why? why do we need to also enable WOL in OS?

My actual problem rise when I implement a WOL program to turn on other PCs in a network(connected by LAN) from a local server. But failed, because it needs some extra configurations in the PCs:

1. The configurations are different from OS to OS (and from version to version).
2. Some of the configurations are not permanent and need to be done in every OS startup. (for example: in Ubuntu 16.04 I had to run ethtool -s eno1 wol g).

Is there any way to bypass the OS configurations and only enable WOL from BIOS settings? Or it's the code problem?

I am trying to transfers a packet from an interface to another by using raw packets (just for playing). First I focused on received packets.

On my machine (archlinux, that has 192.168.30.3 as IP) I created this code:

I have a project which has a docker-compose file and a Dockerfile. The project is open here GitHub

I'm building a demo project with:

• Traefik
• Snort 3
• A NodeJS API dummy for testing

The issue is that in my Docker file I have a command like this to run on Snort

I have developed a XDP program that filters packets based on some specific rules and then either drops them (XDP_DROP) or redirects them (xdp_redirect_map) to another interface. This program was well able to process a synthetic load of ~11Mpps (that's all what my traffic generator is capable of) on just four CPU cores.

Now I've changed that program to use XDP_TX to send the packets out on the interface they were received on instead of redirecting them to another interface. Unfortunately, this simple change caused a big drop in throughput and now it hardly handles ~4Mpps.

I don't understand, what could be the cause for this or how to debug this further, that's why I'm asking here.

My minimal test setup to reproduce the issue:

• Two machines with Intel x520 SFP+ NICs directly connected to each other, both NICs are configured to have as many "combined" queus as the machine has CPU cores.
• Machine 1 runs pktgen using a sample application from the linux sources: ./pktgen_sample05_flow_per_thread.sh -i ens3 -s 64 -d 1.2.3.4 -t 4 -c 0 -v -m MACHINE2_MAC (4 threads, because this was the config that resulted in the highest generated Mpps even though the machine has way more than 4 cores)
• Machine 2 runs a simple program that drops (or reflects) all packets and counts the pps. In that program, I've replaced the XDP_DROP return code with XDP_TX. - Whether I swap the src/dest mac addresses before reflecting the packet did never cause a difference in throughput, so I'm leaving this out here.

When running the program with XDP_DROP, 4 cores on Machine 2 are slightly loaded with ksoftirqd threads while dropping around ~11Mps. That only 4 cores are loaded makes sense, given that pktgen sends out 4 different packets that fill only 4 rx queues becaue of how the hashing in the NIC works.

But when running the program with XDP_TX, one of the cores is a ~100% busy with ksoftirqd and only ~4Mpps are processed. Here I'm not sure, why that happens.

Do you have an idea, what might be causing this throughput drop and CPU usage increase?

Edit: Here some more details about the configuration of Machine 2: