Intel Corporation

Marcos Emanuel Carranza

Francesc Guim Bernat

Karthik Kumar

Cesar Martinez-Spessot

Rajesh Poornachandran

Kshitij Arun Doshi

Mateo Guzman

Mats Gustav Agerstam

Dario Oliver

Justin E Gottschlich

Vincent J Zimmer

Javier Felip Leon

Javier Sebastian Turek

Subrata Banik

Lakshmi N Talluru

Alexander F Heinecke

Maria E Ramirez Loaiza

Krishna Surya

Brian Cremeans

Cesar I Martinez Spessot

Rita H Wouhaybi

John Joseph Browne

Susanne M Balle

Mark D Yarvis

Shengtian Zhou

Thijs Metsch

Mariano Tepper

Mohammad Mejbah Ul Alam

Bin Li

Adrian C Hoban

Mikko Ylinen

Sebastian M Salomon

Wei Seng Yeap

David Cremins

Ravi L Sahita

Satish Chandra Jha

Thomas Willhalm

Mark A Schmisseur

Bahareh Sadeghi

Ignacio Javier Alvarez

Sara S Baghsorkhi

David Israel Gonzalez Aguirre

S M Iftekharul Alam

Jason Martin

Hector A Cordourier Maruri

Paulo Lopez Meyer

Jose Rodrigo Camacho Perez

Javier Perez-Ramirez

Julio Cesar Zamora Esquivel

Robert Colby

Jesus Cruz Vargas

Sindhu Pandian

Benjamin Walker

Ignacio J Alvarez Martinez

Jeffrey Ota

Mustafa Hajeer

Vy Vo

Patrick Koeberl

Tung Lun Loo

Chia Chuan Wu

John Mangan

Charmaine Rui Qin Chan

Haarika Madaka

San Yen Wong

Devamekalai Nagasundaram

System and techniques for abandoned object detection are described herein. a fence is established about a person and an object is detected within the fence. An entry is created in an object-person relationship data structure to establish a relationship between the person and the object within the fence. Then, the position of the object is monitored until an indication that the fence is terminated is received. If it is detected that the object is outside the fence during the monitoring, the person is alerted.

Abandoned object detection

Various systems and methods for implementing intent-based cluster administration are described herein. An orchestrator system includes: a processor; and memory to store instructions, which when executed by the processor, cause the orchestrator system to: receive, at the orchestrator system, an administrative intent-based service level objective (SLO) for an infrastructure configuration of an infrastructure; map the administrative intent-based SLO to a set of imperative policies; deploy the set of imperative policies to the infrastructure; monitor performance of the infrastructure; detect non-compliance with the set of imperative policies; and modify the administrative intent-based SLO to generate a revised set of imperative policies that cause the performance of the infrastructure to be compliant with the revised set of imperative policies.

Intent-based cluster administration

Methods, apparatus, systems and articles of manufacture are disclosed for edge data prioritization. An example apparatus includes at least one memory, instructions, and processor circuitry to at least one of execute or instantiate the instructions to identify an association of a data packet with a data stream based on one or more data stream parameters included in the data packet corresponding to the data stream, the data packet associated with a first priority, execute a model based on the one or more data stream parameters to generate a model output, determine a second priority of at least one of the data packet or the data stream based on the model output, the model output indicative of an adjustment of the first priority to the second priority, and cause transmission of at least one of the data packet or the data stream based on the second priority.

Systems, apparatus, and methods for edge data prioritization

Methods and apparatus for application aware memory patrol scrubbing techniques. The method may be performed on a computing system including one or more memory devices and running multiple applications with associated processes. The computer system may be implemented in a multi-tenant environment, where virtual instances of physical resources provided by the system are allocated to separate tenants, such as through virtualization schemes employing virtual machines or containers. Quality of Service (QoS) scrubbing logic and novel interfaces are provided to enable memory scrubbing QoS policies to be applied at the tenant, application, and/or process level. This QoS policies may include memory ranges for which specific policies are applied, as well as bandwidth allocations for performing scrubbing operations. A pattern generator is also provided for generating scrubbing patterns based on observed or predicted memory access patterns and/or predefined patterns.

Application aware memory patrol scrubbing techniques

Apparatus, devices, systems, methods, and articles of manufacture for intent-based machine programming are disclosed. An example system categorize source code blocks includes a code repository accessor to access a code repository and select a source code block. The example system also includes a signature generator to generate a signature for the source code block, a collateral miner to extract collateral associated with the source code block, and a tokenizer to transform the source code block into tokens. In addition, the example system includes a function assessor to determine a function of the source code block based on the collateral and the tokens and an input/output determiner to determine an input and an output of the source code block based on the collateral and the signature. The example system further includes a tagger to categorize the source code block with the function, input, and output.

Intent-based machine programming

Various systems and methods for implementing intent-based orchestration in heterogenous compute platforms are described herein. An orchestration system is configured to: receive, at the orchestration system, a workload request for a workload, the workload request including an intent-based service level objective (SLO); generate rules for resource allocation based on the workload request; generate a deployment plan using the rules for resource allocation and the intent-based SLO; deploy the workload using the deployment plan; monitor performance of the workload using real-time telemetry; and modify the rules for resource allocation and the deployment plan based on the real-time telemetry.

Intent-based orchestration in heterogenous compute platforms

System and techniques for power-based adaptive hardware reliability on a device are described herein. A hardware platform is divided into multiple partitions. Here, each partition includes a hardware component with an adjustable reliability feature. The several partitions are placed into one of multiple reliability categories. A workload with a reliability requirement is obtained and executed on a partition in a reliability category that satisfies the reliability requirements. A change in operating parameters for the device is detected and the adjustable reliability feature for the partition is modified based on the change in the operating parameters of the device.

Power-based adaptive hardware reliability on a device

Disclosed herein are systems and methods for vehicle-occupancy-based and user-preference-based smart routing, and autonomous volumetric-occupancy measurement. In an embodiment, a system is configured to receive from a user device associated with a user, a routing-options request for routing options between two locations, and to responsively identify one or more routing options between the two locations based at least in part on occupancy data for a vehicle that would be utilized for at least a portion of at least one of the identified routing options. The occupancy data is based on an output of an automated occupancy-measurement system onboard the vehicle. The system is also configured to provide the one or more identified routing options to the user device. In some embodiments, the occupancy data is obtained using volumetric-occupancy measurement. Some embodiments relate to volumetric-occupancy measurement conducted by autonomous mesh nodes.

Systems and methods for vehicle-occupancy-based and user-preference-based smart routing and autonomous volumetric-occupancy measurement

Embodiments described herein are generally directed to the use of sidecars to perform dynamic Application Programming Interface (API) contract generation and conversion. In an example, a first sidecar of a source microservice intercepts a first call to a first API exposed by a destination microservice. The first call makes use of a first API technology specified by a first contract and is originated by the source microservice. An API technology is selected from multiple API technologies. The selected API technology is determined to be different than the first API technology. Based on the first contract, a second contract is dynamically generated that specifies an intermediate API that makes use of the selected API technology. A second sidecar of the destination microservice is caused to generate the intermediate API and connect the intermediate API to the first API.

Dynamic application programming interface (API) contract generation and conversion through microservice sidecars

Techniques for expanded trusted domains are disclosed. In the illustrative embodiment, a trusted domain can be established that includes hardware components from a processor as well as an off-load device. The off-load device may provide compute resources for the trusted domain. The trusted domain can be expanded and contracted on-demand, allowing for a flexible approach to creating and using trusted domains.

Technologies for expanded trusted domains

Embodiments described herein are generally directed to assigning virtual machine (VM) workloads to groupings/partitions of accelerator resources. In an example, a processing resource of a host system maintains: (i) a resource data structure containing resource utilization information for each of one or more accelerators associated with the host system; and (ii) a group data structure containing information regarding each group of multiple groups of one or more virtual functions (VFs) of the one or more accelerators that has been assigned for use by a respective VM of multiple VMs running on a virtual machine monitor (VMM) of the processing resource. A request to deploy a workload associated with a first VM is received. Responsive to the request, the workload is assigned to a VF of a group of the multiple groups determined to have resource capacity available to satisfy expected resource utilization of the workload.

Dynamic routing of workloads to accelerator resources

An apparatus to facilitate provenance audit trails for microservices architectures is disclosed. The apparatus includes one or more processors to obtain provenance metadata for a microservice from a local blockchain of provenance metadata maintained for the hardware resource executing a task performed by the microservice, the provenance metadata comprising identification of the microservice, operating state of at least one of a hardware resource or a software resource used to execute the microservice and the task, and an operating state of a sidecar of the microservice during the task; access one or more policies established for the microservice; analyze the provenance metadata with respect to the one or more policies to identify if there is a violation of the one or more policies; and generate one or more evaluation metrics based on whether the violation of the one or more policies is identified.

Provenance audit trails for microservices architectures

Embodiments described herein are generally directed to a transparent and adaptable mechanism for performing secure application communications through sidecars. In an example, a set of security features is discovered by a first sidecar of a first microservice of multiple microservices of an application. The set of security features are associated with a device of multiple devices of a set of one or more host systems on which the first microservice is running. Information regarding the set of discovered security features is made available to the other microservices by the first sidecar by sharing the information with a discovery service accessible to all of the microservices. A configuration of a communication channel through which a message is to be transmitted from a second microservice to the first microservice is determined by a second sidecar of the second microservice by issuing a request to the discovery service regarding the first microservice.

Secure application communications through sidecars

Embodiments described herein are generally directed to the use of sidecars to perform dynamic Application Programming Interface (API) contract generation and conversion. In an example, a first call by a first microservice to a first API of a second microservice is intercepted by a first sidecar of the first microservice. The first API is of a first API type of multiple API types and is specified by a first contract. An API type of the multiple API types is selected by the first sidecar. Responsive to determining the selected API type differs from the first API type, based on the first contract, a second contract is generated by the first sidecar specifying a second API of the selected API type; and a second sidecar of the second microservice is caused to generate the second API and internally connect the second API to the first API based on the second contract.

Embodiments described herein are generally directed to intelligent management of microservices failover. In an example, responsive to an uncorrectable hardware error associated with a processing resource of a platform on which a task of a service is being performed by a primary microservice, a failover trigger is received by a failover service. A secondary microservice is identified by the failover service that is operating in lockstep mode with the primary microservice. The secondary microservice is caused by the failover service to takeover performance of the task in non-lockstep mode based on failover metadata persisted by the primary microservice. The primary microservice is caused by the failover service to be taken offline.

Management of microservices failover

Growing community of inventors

Portland, OR, United States of America

Marcos Emanuel Carranza