You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> socket creation and kubelet registration. Furthermore, the deployments `securityContext` must
120
120
> be configured with appropriate `runAsUser/runAsGroup`.
121
121
122
+
#### Automatic Provisioning
123
+
124
+
There's a sample [qat initcontainer](https://github.com/intel/intel-device-plugins-for-kubernetes/blob/main/build/docker/intel-qat-initcontainer.Dockerfile). Regardless of device types, the script running inside the initcontainer enables QAT SR-IOV VFs.
| 4xxx, 401xx |[cfg_services](https://github.com/torvalds/linux/blob/42e66b1cc3a070671001f8a1e933a80818a192bf/Documentation/ABI/testing/sysfs-driver-qat) reports the configured services (crypto services or compression services) of the QAT device. |`ServicesEnabled=<value>`| compress:`dc`, crypto:`sym;asym`| Linux 6.0+ kernel is required. |
137
+
138
+
To create a provisioning config after customizing, run as follows:
> **Note**: When deploying the overlay qat_initcontainer, such a manual creation is not necessary since ConfigMap is generated automatically. Just set the values in the config file and deploy the overlay.
144
+
145
+
When using the operator for deploying the plugin with provisioning config, use `provisioningConfig` field for the name of the ConfigMap, then the config is passed to initcontainer through the volume mount.
146
+
147
+
There's also a possibility for a node specific congfiguration through passing a nodename via `NODE_NAME` into initcontainer's environment and passing a node specific profile (`qat-$NODE_NAME.conf`) via ConfigMap volume mount.
148
+
149
+
122
150
#### Verify Plugin Registration
123
151
124
152
Verification of the plugin deployment and detection of QAT hardware can be confirmed by
0 commit comments