From 934892192f088834d1790629aa194440657fc662 Mon Sep 17 00:00:00 2001 From: Jeremy Pare Date: Fri, 2 Aug 2024 10:42:14 -0400 Subject: [PATCH] docs: fixing typos in markdown files Signed-off-by: Jeremy Pare --- CAPABILITIES.md | 2 +- README.md | 2 +- USECASES.md | 2 +- network/README.md | 2 +- storage/frontend_virtio_blk.proto | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/CAPABILITIES.md b/CAPABILITIES.md index 15e58a78..0bfd536d 100644 --- a/CAPABILITIES.md +++ b/CAPABILITIES.md @@ -29,7 +29,7 @@ Application API requirements center around the ability to provide service chaini ### Background -For network applications such as firewalls and load balancers to use DPUs there needs to be significant performanance benefits. Therefore this set of requriements focuses on the areas that require a significant amount of x86 CPU for these type of applications. Ideally the performance improvemenst should be in the range of at least one order of magnitude as there is both a CAPEX and OPEX costs for the end customers. +For network applications such as firewalls and load balancers to use DPUs there needs to be significant performanance benefits. Therefore this set of requirements focuses on the areas that require a significant amount of x86 CPU for these type of applications. Ideally the performance improvemenst should be in the range of at least one order of magnitude as there is both a CAPEX and OPEX costs for the end customers. ### SSL Acceleration diff --git a/README.md b/README.md index d75ea1df..10fcaddf 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ ## I Want To Contribute -This project welcomes contributions and suggestions. We are happy to have the Community involved via submission of **Issues and Pull Requests** (with substantive content or even just fixes). We are hoping for the documents, test framework, etc. to become a community process with active engagement. PRs can be reviewed by by any number of people, and a maintainer may accept. +This project welcomes contributions and suggestions. We are happy to have the Community involved via submission of **Issues and Pull Requests** (with substantive content or even just fixes). We are hoping for the documents, test framework, etc. to become a community process with active engagement. PRs can be reviewed by any number of people, and a maintainer may accept. See [CONTRIBUTING](https://github.com/opiproject/opi/blob/main/CONTRIBUTING.md) and [GitHub Basic Process](https://github.com/opiproject/opi/blob/main/doc-github-rules.md) for more details. diff --git a/USECASES.md b/USECASES.md index ac4e398a..1c13b538 100644 --- a/USECASES.md +++ b/USECASES.md @@ -46,7 +46,7 @@ The API Abstraction Layer provides the interface set for the capabilities provid ![API Control Plane Stacking](doc/images/Control%20Path%20Stacking%20Diagram.png) - A detailed conceptial diagram below illustrates the deployment on the local xPU where the API gateway and load balancer which provides the gRPC/REST interface to the client (client can be an orchestration agent). As part of the abstraction layer, the Authentication and Authorization service is needed to verify the user/agent access and authorization for the service. + A detailed conceptual diagram below illustrates the deployment on the local xPU where the API gateway and load balancer which provides the gRPC/REST interface to the client (client can be an orchestration agent). As part of the abstraction layer, the Authentication and Authorization service is needed to verify the user/agent access and authorization for the service. ![API Abstraction Layer](doc/images/API-Detailed-Abstraction-Layer-Local.png) diff --git a/network/README.md b/network/README.md index 10baa66f..a6f9f4a5 100644 --- a/network/README.md +++ b/network/README.md @@ -5,7 +5,7 @@ - OPI defines/recommends __protobuf__ definitions that each vendor can tie into the underlying SDKs. - The __protobuf__ definitions will be aligned with the API and behavioral models available from OVS DB, OpenConfig, OpenFlow, P4, etc. to allow configuration of the service. - OPI provides a __LAN service__ implementation for the network capabilities that is compatible with OVS, SONiC, VPP, P4, etc. -- OPI defines a __device interface__ for the data services that are delivered through the the PF/VF from the xPU. +- OPI defines a __device interface__ for the data services that are delivered through the PF/VF from the xPU. - OPI provides a __prototype client__ for sending gRPC, REST protobufs to the xPU for configuation and management. ## Network APIs to be defined diff --git a/storage/frontend_virtio_blk.proto b/storage/frontend_virtio_blk.proto index 463de062..813c20d4 100755 --- a/storage/frontend_virtio_blk.proto +++ b/storage/frontend_virtio_blk.proto @@ -19,7 +19,7 @@ import "google/api/annotations.proto"; import "google/api/field_behavior.proto"; import "google/protobuf/field_mask.proto"; -// Front End (host-facing) APIs. Mostly used for Virtio-blk emulation emulation and host presentation as alternative to Nvme. +// Front End (host-facing) APIs. Mostly used for Virtio-blk emulation and host presentation as alternative to Nvme. service FrontendVirtioBlkService { // Create an Virtio Blk rpc CreateVirtioBlk (CreateVirtioBlkRequest) returns (VirtioBlk) {