Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding in support for Azure Netvsc. #960

Open
HackTheMak opened this issue Jun 26, 2024 · 4 comments
Open

Adding in support for Azure Netvsc. #960

HackTheMak opened this issue Jun 26, 2024 · 4 comments

Comments

@HackTheMak
Copy link

We're attempting to get Suricata with Netmap to perform in Azure and I have checked with the net and of the issues here with regards to it, with one in 2017 (closed). That one mentioned of referring to virtio-net as an example. We're willing to do the coding/testing (and provide the files as well) to implement it with Netmap, just need some guidance as to which files to create.
Performance wise is to work with the possible high Gbps for Azure.

@vmaffione
Copy link
Collaborator

There are two approaches.
The first (and probably easier/preferred) one is the "external drivers" one, where basically netmap downloads the original source code from the Internet (for a given version), patches it and compiles the patched kernel module.
You will need

  1. A netmap patch. For virtio_net the patch is is https://github.com/luigirizzo/netmap/blob/master/LINUX/final-patches/custom--virtio_net.c--4.9
  2. Netmap support header. FOr virtio_net the header is https://github.com/luigirizzo/netmap/blob/master/LINUX/if_virtio_net_netmap.h
  3. Modifications to the build system, e.g. https://github.com/luigirizzo/netmap/blob/master/LINUX/configure and https://github.com/luigirizzo/netmap/blob/master/LINUX/default-config.mak.in_ (but I'm not able to give more details on this)

The second approach is using the sources from the running kernel, and still ofc applying a patch. The problem is that there are so many versions of the driver that you need to prepare many patches, and this is complex. Also, for the case of virtio-net the driver evolves very quickly, so that the problem becomes even worse.

@HackTheMak
Copy link
Author

Ok, thanks for replying.
So in theory, in simplest terms, is to use the Virtio files as listed above as templates for the Azure NICs. Then modify the build systems files as above.

@HackTheMak
Copy link
Author

Would it be possible to use the AWS ENA files as a reference to the modify the Azure MANA files? This avoids modifying the Netmap files from the looks of it. The reason asking of this, is that for FreeBSD, the ENA files have Netmap coding within them, thus allows Netmap to support ENA. I assume that would be the second approach method that was mentioned.
Example:
AWS ENA Files: https://github.com/freebsd/freebsd-src/tree/main/sys/dev/ena
MS MANA Files: https://github.com/freebsd/freebsd-src/tree/main/sys/dev/mana

@vmaffione
Copy link
Collaborator

It is possibile. And yes, that would be the second approach. I thought you wanted to work on Linux, so my answer was set on this assumption.
If you want to add netmap support for FreeBSD, instead, then it's actually easier. You can just submit a patch to the FreeBSD project (changes to the MANA driver plus the MANA netmap header implementing txsync/rxsync and the other netmap callbacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants