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

Upstream vale port type extraction #569

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

garrettkajmowicz-sophos
Copy link
Contributor

Adds some logic which we have found to be useful. Namely, provide a way to determine what type of VALE port we are dealing with. This is useful to identify configuration issues or to be able to take different actions based on where the data is coming from.

…19-upstream-vale-port-type-extraction to master

* commit '0611cef314f524741c9ea3ad80bf3cd85634cc1a':
  Change constant names to reflect upstream standards.
  Add port type information to vale-ctl output.
  Add additional checks to identify a vale Physical port
  Add a port type return value for NETMAP_BDG_LIST command
@@ -324,6 +324,7 @@ nmreq_to_legacy(struct nmreq_header *hdr, struct nmreq *nmr)
strlcpy(nmr->nr_name, hdr->nr_name, sizeof(nmr->nr_name));
nmr->nr_arg1 = req->nr_bridge_idx;
nmr->nr_arg2 = req->nr_port_idx;
nmr->nr_arg3 = req->nr_port_type;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is legacy API, and therefore can't be changed.

VALE_PORT_T_ERROR = 0,
VALE_PORT_T_PHYS = 1,
VALE_PORT_T_STACK = 2,
VALE_PORT_T_VIRT = 3,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we distinguish between ephemeral vale ports and persistent vale ports (e.g. created with vale-ctl -n?)

@vmaffione
Copy link
Collaborator

Hi,
We discussed with @giuseppelettieri , and we think it is necessary to change the approach to play with this kind of port-type information.
Trying to recover the port type by peeking inside pointers of the netmap adapters is very fragile (w.r.t. changes) and unnecessarily complex. Also, we should make this mechanism more generic, and make it possible to recover the port-type also for non-VALE ports.

A better approach is to add an adapter_type or port_type enum field to the struct netmap_adapter, so that any netmap port has a port type. The adapter_type field is set when the netmap adapter struct is created. This may be netmap_attach for NIC ports, netmap_get_null_na for null ports, netmap_get_pipe_na for pipe ports, etc. You can look at the netmap_get_na function to see all the ports that we support.

Once we do this, we can extend the struct nmreq_port_info_get to retrieve the additional adaper_type field. We can also add this field to struct nmreq_vale_list, as your original change did.

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.

None yet

2 participants