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

Send packets to controller from the running program #292

Merged
merged 2 commits into from
Apr 28, 2020

Conversation

FedeParola
Copy link
Collaborator

@FedeParola FedeParola commented Apr 26, 2020

This PR allows to send packets to the controller from the running program and then continue with the processing.
pcn_pkt_controller() now returns the return value of bpf_perf_event_output() helper.
Formerly packets were sent to the controller through a dedicated program executed via tail call and they could not be further processed in the datapath.
Fixes #281.

In details:

  • The code of the two programs (CTRL_TC_TX and CTRL_XDP_TX) responsible of sending packets to the controller has been moved from the Controller class (controller.cpp) to the pcn_pkt_controller() helper in classes CubeTC (cube_tc.cpp), CubeXDP (cubec_xdp.cpp), TransparentCubeTC (transparent_cube_tc.cpp) and TransparentCubeXDP (transparent_cube_xdp.cpp) with minor modifications.
    Standard and transparent versions of this code differ in the fact that standard code uses the port_id filed of metadata to store the port, while transparent version uses it to store the direction of the packet.
  • Controller class now only instantiate two perf rings used to send packets to user plane (controller_tc and controller_xdp), declared as public tables, and then polls on them to retrieve the packets and forward them to the corresponding cube.
    The code responsible of sending packets back to the fast path was not modified.
  • pcn_pkt_controller_with_metadata_stack() helper has been removed since the calling program can send the packet to the controller and then let it proceed to the stack returning RX_OK.
  • All services using the pcn_pkt_controller() helper (except from packetcapture) have been updated to call the helper and then return RX_DROP, in order to keep the same behavior as before.
    The packetcapture returns RX_OK to let the packet pass.

@FedeParola FedeParola requested a review from a team as a code owner April 26, 2020 11:55
@frisso
Copy link
Contributor

frisso commented Apr 26, 2020

This should make PR #270 obsolete.

@frisso
Copy link
Contributor

frisso commented Apr 26, 2020

@FedeParola, given the rather large amount of code that is involved in this PR, I would suggest to briefly explain how you changed the code, even here as a comment in this PR. Thanks!

@FedeParola
Copy link
Collaborator Author

@FedeParola, given the rather large amount of code that is involved in this PR, I would suggest to briefly explain how you changed the code, even here as a comment in this PR. Thanks!

Added more details in the PR description, let me now if there is still something not clear.

@goldenrye
Copy link
Contributor

@FedeParola a little late to review the the code, does this change fixes the problem or only refactoring the code?
"Formerly packets were sent to the controller through a dedicated program executed via tail call and they could not be further processed in the datapath."
I am arguing with this - in existing design, the packet can still be processed if the dedicated program return value 0.

@FedeParola
Copy link
Collaborator Author

@FedeParola a little late to review the the code, does this change fixes the problem or only refactoring the code?

If you mean the problem in issue #281, yes, it is fixed.
There is still the problem that I mentioned in my comment to that issue though.
When a packet goes to the controller and then is sent back to the fast path through send_packet_out(), the ingress interface seen by the kernel is different from the original one (it is either pcn_tc_cp or pcn_xdp_cp) and this can cause problems.

"Formerly packets were sent to the controller through a dedicated program executed via tail call and they could not be further processed in the datapath."
I am arguing with this - in existing design, the packet can still be processed if the dedicated program return value 0.

You are right, the packet can still be processed by the network stack. With that sentence I meant that the packet can not be further processed by the ebpf program, unless you send it to the controller and then send it back to the fast path, with a decrease in performance and the problem described above.

@frisso frisso merged commit 642c19b into polycube-network:master Apr 28, 2020
@FedeParola FedeParola deleted the controller-direct branch April 28, 2020 06:57
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

Successfully merging this pull request may close these issues.

interface won't be reached with packetcapture cube attached
4 participants