Kernel: Linux Security and Graphics
-
Why eBPF is the Future of Linux and Cloud Native Networking
For decades, IPtables has been the cornerstone of Linux networking, but that's no longer the case. Over the last few years, extended Berkeley Packet Filter (eBPF) has emerged as a better option for Linux whether it's running on-premises, or more likely than not, in the cloud.
What eBPF provides is a low-level interface to enable data packet transmission and control. On its own it has tremendous potential for networking. While there is lots of open source eBPF code now in the Linux kernel, on its own, it can be quite complex, which is where the open source Cilium project has been making inroads in the last few years.
I first wrote on Cilium in 2017, when the project first got started and the company behind it - Isovlanet - was still shrouded in stealth. Cilium and Isovalent are led by CEO and co-founder Dan Wendlandt, who helped to create the OpenStack Quantum networking project and was a pioneer in the Software Defined Networking (SDN) industry at VMware.
Last week, Isovalent emerged from stealth, along with $29 million in funding led by Andreessen Horowitz. Wendlandt and Andreessen Horowitz are hardly strangers; after he left VMware in 2016 he went to work as a partner at the venture capital firm, alongside fellow SDN pioneer and VMware alum Martin Casado.
-
[Mesa-dev] Intent to retire ancient driver support
Sending this on to the list for visibility, since not everyone follows everything on gitlab. In this merge request: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7660 I retire support for DRI drivers older than Mesa 8.0, which was February 2012. In particular this retires the ability for libGL to even load DRI1 drivers, which last existed in Mesa 7.11. We are not aware of any currently supported distros trying to ship both DRI1 drivers and anything newer. In fact the only distro I'm aware of that ever _tried_ was RHEL 6, which goes into extended-life support at the end of the month, and which is currently shipping Mesa 11.0.7 and is thus _way_ behind the times in terms of hardware enablement. Eric Anholt suggested that glvnd is the better way to retain DRI1 support at this point, and to that end there is also: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7674 Which allows us to override the glvnd vendor name. xserver could then select a different name for DRI1 screens, and now you get parallel-installable Mesa packages, which could be nice for a bunch of reasons. If you still care about DRI1 support, I am very sorry, but hopefully !7674 (backported to 20.x) and a bit of polish to xserver should keep things working for you, and your feedback/testing would be greatly appreciated.
-
Mesa To Drop Support For Ancient Drivers - Phoronix
The fallout should be minimal and hopefully not impact any Phoronix readers, but as Mesa rolls into 2021 it is looking to drop support for loading DRI1 graphics drivers.
Back in 2011 the classic Radeon drivers were removed Adam Jackson of Red Hat is planning to remove the ability for Mesa's current libGL to be able to load DRI1 drivers. This is basically about trying to load old DRI1 drivers from Mesa pre-8.0 onto a system with the current Mesa libGL loader. Mesa has retained this ability for being able to load these classic DRI1 drivers but nearly nine years after old driver code was dropped from Mesa, phasing out this ability to load DRI1 drivers is now planned.
-
Arcturus No Longer Experimental - AMD Instinct MI100 Linux Support Is Ready - Phoronix
Being sent in as a "fix" this week to the Linux 5.10 kernel is removing the experimental flag for the Arcturus GPU, days after AMD announced the MI100 accelerator at SC20.
Going back to the summer of 2019 there have been Linux graphics driver patches for "Arcturus" as an evolution of GFX9/Vega but with not a lot being known about it. Much work was poured into this open-source driver code for Arcturus and the Linux support all squared away over the past year. This week it finally entered the limelight in the form of the AMD Instinct MI100 accelerator.
-
NVIDIA Is Working On Vulkan Support With RDMA Memory - Phoronix
Well this will be interesting to see what NVIDIA use-case pans out... NVIDIA engineers are working on a Vulkan extension for making use of RDMA memory.
Remote Direct Memory Access (RDMA) for zero-copy networking with high throughput and low latency is very common for cluster computing and other enterprise scenarios to allow direct memory access from one computer to another without the intervention of the CPU. NVIDIA now though is preparing to support RDMA memory usage in the Vulkan context.
- Login or register to post comments
- Printer-friendly version
- 3251 reads
- PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
digiKam 7.7.0 is releasedAfter three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release. |
Dilution and Misuse of the "Linux" Brand
|
Samsung, Red Hat to Work on Linux Drivers for Future TechThe metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world. Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility. |
today's howtos
|
Recent comments
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago