Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[vslib]Add MACsec forward and filters to HostInterfaceInfo #719
[vslib]Add MACsec forward and filters to HostInterfaceInfo #719
Changes from 1 commit
8b4cb33
fe58aaa
8b7f3f8
38be8ab
f98468c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why you need separate thread in macsec ? there is already thread thats deals with packet processing, why not tap into that ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we already have 2 threads per port that transfer the data, and you are having some another thread for the path that is already processing data, this seems a waist of resources
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember you asked this question before, sorry that I did not explain it clear.
I think we need three threads in current design. The previous two are for forwarding data between tap and veth, and the new one is for forwarding the plaintext data from macsec to tap.
Meanwhile, all encrypted data on the thread 2 will be dropped by the macsec ingress filter. Because linux kernel will help us to forward the encrypted data.
All plaintext data, except EAPOL traffic, from tap interface will be captured by the MACsec egress filter that forwards to the macsec device for encryption.
Who will help us to forward the plaintext data from macsec device? I believe it should be thread 3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so mu understanding here is now like this: we have regular traffic, and encrypted traffic coming to the same interface then based on something (dont know what it is) you can distinguish which one is which, and for encrypted traffic you are sending this traffic to separate created socket that will decrypt this traffic inside kernel and then you can read that socket (or other one?) to get planetext traffic, process it, block or forward, maybe generate fdb notification, and then forward back encrypted traffic (re-encrypted if some filters are applied that modify pakcket) to the existing tap device?
if this is the case, both encrypted and plain text traffic come to the single tap interface, and right now this traffic is processing 1 by 1 packet in order that they arrived, with your async solution there is possibility that arrived packets will be reordered, and this is probably whats not happening in real hardware, but thats my guess. Anyway in this case i think you should block for processing in the pipeline.
if my understanding here is wrong, please setup a call meeting with me, we can talk and share on teams. I'm in CET timezone and available from 11am to 10pm everyday
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
basically this MACsecForwarder::forward() is exactly the same as HostInterfaceInfo::veth2tap_fun, but not having this filter option, and just uses different FD, but other processes are the same, i think this could be somehow unified, but maybe not this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. I add a new super class
TrafficForwarder
. Maybe we can leverage it to refactor this part in the another PR.