Skip to content

Commit

Permalink
Merge pull request #1439 from mythi/PR-2023-029
Browse files Browse the repository at this point in the history
doc and version updates
  • Loading branch information
hj-johannes-lee committed May 31, 2023
2 parents 819d302 + 93bea62 commit 5e597d2
Show file tree
Hide file tree
Showing 3 changed files with 7 additions and 7 deletions.
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -166,10 +166,10 @@ as a standalone [SGX Admission webhook image](cmd/sgx_admissionwebhook/README.md
#### Intel SGX EPC memory registration

The Intel SGX EPC memory available on each node is registered as a Kubernetes extended resource using
node-feature-discovery (NFD). A custom NFD source hook is installed as part of
node-feature-discovery (NFD). An NFD Node Feature Rule is installed as part of
[SGX device plugin](cmd/sgx_plugin/README.md)
operator deployment and NFD is configured to register the Intel SGX EPC memory
extended resource reported by the hook.
extended resource.

Containers requesting Intel SGX EPC resources in the cluster use
`sgx.intel.com/epc` resource which is of
Expand Down
4 changes: 2 additions & 2 deletions cmd/sgx_plugin/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ Table of Contents
The Intel SGX device plugin and related components allow workloads to use Intel SGX on
platforms with SGX Flexible Launch Control enabled, e.g.,:

- 3rd Generation Intel® Xeon® Scalable Platform, code-named “Ice Lake”
- 3rd/4th Generation Intel® Xeon® Scalable Platforms
- Intel® Xeon® E3
- Intel® NUC Kit NUC7CJYH

Expand Down Expand Up @@ -122,7 +122,7 @@ $ kubectl apply -k 'https://github.com/intel/intel-device-plugins-for-kubernetes
$ kubectl apply -k 'https://github.com/intel/intel-device-plugins-for-kubernetes/deployments/sgx_plugin/overlays/epc-nfd/'
```

The second approach has a lesser deployment footprint. It does not require NFD, but a helper daemonset that creates `sgx.intel.com/capable='true'` node label and advertises EPC capacity to the API server.
The second approach has a lesser deployment footprint. It does not require NFD, but a helper daemonset that creates `sgx.intel.com/capable='true'` node label and advertises EPC capacity directly to the API server.

The following kustomization is used for this approach:
```bash
Expand Down
6 changes: 3 additions & 3 deletions demo/openssl-qat-engine/Dockerfile
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
FROM ubuntu:22.04 as builder

ARG QATLIB_VERSION="23.02.0"
ARG QAT_ENGINE_VERSION="v0.6.19"
ARG QAT_ENGINE_VERSION="v1.1.0"
ARG ASYNC_NGINX_VERSION="v0.5.0"
ARG IPSEC_MB_VERSION="v1.3"
ARG IPP_CRYPTO_VERSION="ippcp_2021.7"
ARG IPP_CRYPTO_VERSION="ippcp_2021.7.1"

RUN apt update && \
env DEBIAN_FRONTEND=noninteractive apt install -y \
Expand Down Expand Up @@ -74,7 +74,7 @@ COPY --from=builder /usr/bin/*_sample* /usr/bin/
COPY --from=builder /usr/lib/libqat.so.3.0.3 /usr/lib/
COPY --from=builder /usr/lib/libusdm.so.0.1.0 /usr/lib/
COPY --from=builder /usr/lib64/libIPSec_MB.so.1 /usr/lib/x86_64-linux-gnu/
COPY --from=builder /usr/local/lib/libcrypto_mb.so.11.5 /usr/lib/x86_64-linux-gnu/
COPY --from=builder /usr/local/lib/libcrypto_mb.so.11.6 /usr/lib/x86_64-linux-gnu/
COPY --from=builder /usr/lib/x86_64-linux-gnu/engines-3/qatengine.so /usr/lib/x86_64-linux-gnu/engines-3/qatengine.so
COPY --from=builder /var/www/ /var/www/
COPY --from=builder /usr/lib64/nginx/* /usr/lib64/nginx/
Expand Down

0 comments on commit 5e597d2

Please sign in to comment.