mkubecek
Porting Twinkle to Qt5
an invention by mkubecek
Twinkle, my favourite SIP client, seems no longer developed, has been accused of "bitrotting" and even dropped from some distributions. While I don't believe in bits actually rotting, there is one pressing issue: twinkle uses Qt3. While there are some patches reportedly allowing to build twinkle with Qt4, e.g. here, all seem to use a Qt3 compatibility layer of Qt4 which has been dropped in Qt5, AFAIK, so that those won't be very future-proof either.
Make Intel baytrail based device(s) work better with openSUSE
a project by mkubecek
Recently I became a (not very proud) owner of Acer Aspire Switch 10E, a small notebook/tablet convertible based on Intel baytrail platform. Replacing preinstalled (32-bit!) Windows 8.1 with (64-bit) openSUSE proved more challenging than expected, mostly because the device is haunted by a 32-bit UEFI so that it took me a week to make it boot without an external USB flash disk. Even today, a lot of issues persist. As I do not want to waste a (partially) good hardware, I would like to make it as usable as possible. This is much less selfish than it sounds as there are many other devices based on Intel baytrail platform so that the effort is going to help their owners as well (if successful, that is).
netlink interface for ethtool
a project by mkubecek
There seems to be an overall consensus that the ioctl interface used by ethtool is a poor design as it's inflexible, error prone and notoriously hard to extend. It should clearly be replaced by netlink and obsoleted. Unfortunately not much actual work has been done in that direction until this project started. The project started in Hackweek 16 (fall 2017) and has been worked on since, both in Hackweek 17-19 and outside. First two parts of kernel implementation are in mainline since 5.6-rc1, first part of userspace implementation (ethtool utility) has been submitted to upstream at the end of Hackweek 19 (2020-02-16).
ethtool ops for netdevsim
a project by mkubecek
This can be seen as a subproject of ethtool netlink interface but from the technical view it's independent. Every new piece of software is going to be buggy and with frequent changes and rewrites, new regressions are introduced. Automated selftests can help a lot but as ethtool deals with hardware devices, we do not want these tests to depend on a specific hardware. The netdevsim driver was created as a virtual device which (unlike e.g. dummy) cannot be used for actual network traffic but implements various configuration interfaces so that it can be used for their (automated) testing.
make "predictable network interface names" more predictable
an idea by mkubecek
Since the so-called "predictable names" for network interfaces were introduced, the concept and mainly its implementation has been a target of a lot of critique and sometimes even hate. On the other hand, similar idea works reasonably well for block devices. In my opinion, the main reason why "predictable names" reception was not nearly as good as for block devices is the difference in how the implementation works. For block devices, the device name provided by kernel is preserved and other names based on multiple naming schemes (by path, by UUID, by various device identifiers) are created as symlinks so that all of them (including the original kernel one) can be used simultaneously. On the other hand, network interface has only one name and as it is not represented by a file, symlinks cannot be used for aliases. Therefore even if there are multiple naming schemes (e.g. based on BIOS enumeration, bus address etc.), only one of them can be used for each network device and it's rather unpredictable which one is it going to be. Moreover, some of the generated names are rather long, ugly and inconveninent and unlike with block devices, one cannot just ignore them and use a different name (e.g. one provided by kernel).
multithreaded network benchmark
an invention by mkubecek
Project Description
There are multiple network benchmark tools already, most popular probably being netperf and iperf. Each of them has its pros and cons but the biggest drawback probably is that netperf runs only one connection (flow) and while iperf can use multiple connections, it still runs in a single thread. For benchmarking of contemporary fast networks like 40Gb/s or 100Gb/s ethernet, this can be a severe limitation as the performance is often CPU bound. Even on 10Gb/s ethernet, we are often unable to saturate the medium if tunneling or complex packet processing is involved.
Activity