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

implement sriov token server chain element #246

Closed
pperiyasamy opened this issue Aug 18, 2021 · 3 comments · Fixed by #249
Closed

implement sriov token server chain element #246

pperiyasamy opened this issue Aug 18, 2021 · 3 comments · Fixed by #249
Assignees

Comments

@pperiyasamy
Copy link
Member

The sdk-sriov repo already contains sriov token client chain element which can be used by NSCs to create service request with tokenID to request for VF attachment.
But there is no server chain element exists so that NSEs can issue available token id via mechanism parameter for every client connection request, this token id can be later used by forwarder to attach a dedicated VF for every client connection. This chain element should be also an idempotent for the existing client connection. When no tokens are present for new client connections, then consider skipping it and execute subsequent chain element.

@pperiyasamy
Copy link
Member Author

/cc @edwarnicke @JanScheurich

@edwarnicke
Copy link
Member

@pperiyasamy Would it make sense here to simply include the token in the Mechanism returned by the NSE?

@pperiyasamy
Copy link
Member Author

pperiyasamy commented Aug 18, 2021

@edwarnicke just returning token id might work for dedicated VF case (i.e. one VF per client connection).
In this case, NSE is brought up with required sriov resources upfront based on number of clients it would serve.
The sriov token server element is initialised with allocated token id list, then it would assign a token from the list and send it in mechanism parameter for every client connection request.

I thought storing (via resource pool client communicating assigned VF pci address back into NSE with another service request) and then sending VF pci address into mechanism parameter might be useful for VLAN sub interface case. can we implement this later ?

or you have other thoughts ?

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 a pull request may close this issue.

2 participants