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
121
121
> be configured with appropriate `runAsUser/runAsGroup`.
122
122
123
+
#### Automatic Provisioning
124
+
125
+
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. |
138
+
139
+
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.
145
+
146
+
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.
147
+
148
+
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.
149
+
150
+
123
151
#### Verify Plugin Registration
124
152
125
153
Verification of the plugin deployment and detection of QAT hardware can be confirmed by
0 commit comments