Hi.
This NIC is getting more and more used in small router boxes +++.
Is it possible to add support for the Intel i225-V NIC?
What you mean with: “add support for the Intel i225-V NIC?”
What support for what?
(Too vague request are perfecly discarded, also some perfectly described)
.
By adding the drivers for the Intel i225-V network chips for the x86 and CHR versions of RouterOS.
I believe they are already in RouterOS v7
.
Doesn’t seem like it. No ethernet adapters found…
+1 for this
keep in mind there are several revisions of this NIC
Intel i225V (rev 3) being the most relevant today
+1
the device show in pci devices it but there is no network interface
ROS 7.4beta2 x86_64
I see problem stories using this card under Linux dated earlier in this year, so probably it is not a matter of “it works in the default kernel”.
And maybe it is solved in a later kernel version but of course v7 will (like v6) at some time freeze to a certain kernel version and we can expect that “new” devices again will become problematic over time.
x86 ROS is dead or dying, and CHR leaves the hardware support to the hypervisor, as it should. I suggest using CHR.
CHR can leave hardware NIC support to the hypervisor but that have a significant performance penalty
if CHR support the NIC, you can configure hypervisor to do passthrough improving performance dramatically, close to bare-metal
Concur! Serious controller manufacturers develops device drivers that supports Single Root I/O Virtualization (SR-IOV) which enables hardware to run as “bare metal” using hypervisors like for example VMware ESXi and Microsoft Hyper-V. This is the way! 
.
Yes, but problem is that the i225-v doesn’t support SR-IOV…
You can now get a small fanless box with an Intel N5105 CPU and 4xi225-v NICs for around $160. These are great for running Proxmox with a few VM’s.
Without proper driver support for the i225-v in RouterOS CHR to do pci-e passthrough, you are not getting the best possible performance. Remember these NICs support 2.5G…
It would be great if Mikrotik were to include the drivers for them.
Did you already investigate if “standard Linux distributions” support this out-of-the-box?
Did you need to install a driver or firmware package?
@McKajVah, MT abandoned general support for Linux/x86 many years ago. http://forum.mikrotik.com/t/routeros-x86-supported-hardware-and-drivers/126332/1
There is proper driver support for I225V in Linux, Windows and VMware ESXi using high speed DMA transfers. However, it’s up to the manufacturer (ie Intel in this case and not MT) to adjust and fine tune the device drivers for the intended use.
In general there are tons of low-cost high speed NIC’s with good enough device drivers for home usage. I’m pretty sure you will be able to achieve close to max speed with CHR using 4 or 8 line pcie and the standard drivers.
Regarding SR-IOV it’s all about load during concurrent processing that probably isn’t vital in case of regular home usage.
@Larsa: I don’t understand why you seem to be against it. There are now several people just in this thread wanting Mikrotik to support the i225-v directly.
Also to me it still seems that Mikrotik are actively developing the x86 version, just see latest stable release with support for new NICs, fixes, etc…
We are just asking Mikrotik to support the i225-v directly, don’t put more into it than that.
.
yes, it is included in newer distributions. Seems i225-v support was included in kernel 5.6.
From 5.6 changelog: “Add SKU for i225 device commit”.
I’m not against anything but maybe we just talk past each other.
What I’m trying to say is that if you need to support “bare metal” installation for a ROS Appliance it’s like any regular installation of Windows or Linux direkt on hardware. It means a huge undertaking to constantly sort out what public available hardware to support and commit to long time maintenance of related device drivers which is unrealistic for a company like MT.
However If you instead virtualise it all, you put the entire responsibility on the hardware manufacturers for operation and maintenance of device drivers. Also, nowadays the virtualisation has become so effective the difference in speed for I/O barely is measurable compared to a regular installation.
Bottom line, make use of CHR since it makes all much easer, both for the end user and MT as a developer. And you also get full support for I225V.
It would not be that unrealistic when they just get the “default kernel” with all included drivers compiled as modules and replace that once or twice a year.
But apparently they do a lot of other kernel patches for RouterOS and it is a lot of work to re-do those every time. It took like 10 years between v6 and v7 to change kernel version once.
I do not know if it is much easier now, and how often they are going to do it now. Apparently the current kernel is from (just) before the i225-V support, and now the users of that card are out of luck.
It could 10 years again before a newer kernel is used, or this time it could be a little sooner. We don’t know.
One of the major advantages of Linux is the modularity but that’s also the biggest challenge as you need to customize the whole configuration to meet specific requisites thus there is not really a general “standard kernel” (but I gather you meant a “MT standard” kernel).
There are also both static and dynamic loadable device drivers which may or may not conflict depending on certain circumstances. Also, depending on the driver type the api may differ between kernel versions and new/changed features incorporated.
And just because a device driver is available it doesn’t mean it’s painless to incorporate it into the kernel since there are usually a lot of different factors to consider.
All this is a hole friking lot of work so besides getting all this to work just on the current MT hardware it would be a nightmare to also be forced supporting a general “Linux Appliance”.
That said, IMHO there is no point to argue about a regular Linux build now when CHR is available, is it?
Please don’t rehash descriptions of the situation 20-25 years ago!
Today with PCIe cards, those conflicts do no longer occur. You can compile a kernel with all drivers compiled as modules, and it just works.
That is what distributors like Debian, RedHat etc do. You install the system, it detects the hardware by PCI ID and loads the correct drivers. No problem.
What makes it difficult to support “all hardware” that each card is supported only from some specific X.Y.Z kernel version onwards, and at the moment you freeze on a kernel version you also freeze the hardware support. Backporting all newer drivers for newer hardware, THAT would consume a lot of resources and would be hard to do. We have seen it happen in RouterOS v6 but it became harder and harder the further the kernel became out of date.
Maybe this time the request is implemented and the support appears in some future RouterOS v7 x86 version, who knows.
(probably at this time it is still “easy to do”)