Comments (9)
@JanScheurich currently its not, but in case of ovs forwarder, let it create a service request with interface name in mechanism preference parameter and let NSE use it for mapping afterwards. but application have to find a way to retrieve PCI device address using interface name.
I believe there are lots of ways of retrieving the PCI information for an interface:
$ ethtool -i eth0
driver: i40e
version: 1.5.16
firmware-version: 5.04 0x800024cd 0.0.0
bus-info: 0000:06:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
and https://github.com/safchain/ethtool
from sdk-sriov.
Sounds good to me.
@Bolodya1997 Looks like it is related to your owning component. Could you also take a look at the suggestion?
from sdk-sriov.
We can extract some common logic and create a client chain element, but there is some basic problem with it.
When we are selecting VF for the Client requesting VFIO mechanism we have such scheme:
Client --( token ID )-> Forwarder
Client <-(IOMMU group)-- Forwarder
With Endpoint there will be another scheme:
Forwarder --( )-> Endpoint
Forwarder <-(token ID)-- Endpoint
So the only way to pass IOMMU group back to the Endpoint is to make second Request from the Forwarder. And there is no way to make this selection before we get token ID from the Endpoint.
So yes, we can add some client chain element to select a VF for the Endpoint and inject it in there, but there will be a problem to tell what we have selected back to the Endpoint.
@pperiyasamy is this a problem? Or probably you just don't want to pass something back to the Endpoint and so it is OK to you?
from sdk-sriov.
@Bolodya1997 Good find! in case of smartnic scenario, the VF would be just a kernel interface (also can be used as a DPDK device) configured inside endpoint container with IP address and routes (though interface name is derived in the forwarder) sent by endpoint upon service request. I hope that would be sufficient for endpoint to figure out which interface belongs to which p2p network in case if that's needed by endpoint application, it also has to have extra logic to figure out pci address of the VF device in dpdk scenario.
/cc @JanScheurich
from sdk-sriov.
Mellanox SRIOV VFs are always bound to their mlx5_core kernel driver, so the netdev will be visible to the NSE pod.
As long as the NSE can map the interface name in the pod to the connected client, we should be fine. It is possible to map the netdev to the PCI device address for use with DPDK. Is the netdev interface name signaled to the NSE in the service request?
from sdk-sriov.
@JanScheurich A question (to make sure I understand :) ).
Mellanox SRIOV VFs are always bound to their mlx5_core kernel driver, so the netdev will be visible to the NSE pod.
- Am I correct that by 'netdev' you mean the kernel interface for the SRIOV VF?
- If I'm correct about that, do you mean you want the netdev inserted into the NSE Pods Namespace, or do you mean it is inserted into the NSE Pods namespace?
- If you mean it is inserted into the NSE Pods namespace, how exactly is that happening?
from sdk-sriov.
Am I correct that by 'netdev' you mean the kernel interface for the SRIOV VF?
Yes
If I'm correct about that, do you mean you want the netdev inserted into the NSE Pods Namespace, or do you mean it is inserted into the NSE Pods namespace?
The SmartVF netdevs must be inserted into the NSE and NSC pod namespaces. Otherwise the NSC/NSE could not use it at all neither via kernel networking, nor as DPDK interface, nor as RDMA interface.
If you mean it is inserted into the NSE Pods namespace, how exactly is that happening?
That's the job of the OVS forwarder. It injects in into the pod namespace and applies all the usual interface configuration for a kernel interface.
from sdk-sriov.
Is the netdev interface name signaled to the NSE in the service request?
@JanScheurich currently its not, but in case of ovs forwarder, let it create a service request with interface name in mechanism preference parameter and let NSE use it for mapping afterwards. but application have to find a way to retrieve PCI device address using interface name.
from sdk-sriov.
That's the job of the OVS forwarder. It injects in into the pod namespace and applies all the usual interface configuration for a kernel interface.
Got it... that's answers my question... the way you had phrased it sounded like you expected it to already be there before the Forwarder did its work. Happy to have misunderstood there :)
from sdk-sriov.
Related Issues (15)
- Compact PCIAddress list instead of multiple mechanisms. HOT 3
- SR-IOV forwarder fails with panic on NSMgr restart
- adapt to use connectioncontextkernel from sdk-kernel
- sdk-sriov has dataraces
- sdk-sriov is not updated to latest sdk-kernel HOT 6
- implement sriov token server chain element HOT 3
- Add support for sriov 'vlan' or 'vxlan' remote mechanism HOT 2
- VFIO tests are unstable
- unit test TestVFIOServer_Request is unstable on ci
- unit test TestVFIOServer_Close is unstable on ci
- Rework VFIO Tests
- Make SRIOV VFs to push/pop tags like vlan or vxlan HOT 7
- Add config reader for endpoint
- Reset all VFs for the PF on creation
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sdk-sriov.