用于动态缓存引擎指令的处理器、方法、装置和设备

摘要

一般而言，在一方面，本公开描述包括指令储存器和耦合到所述指令储存器的一组多个引擎的处理器，所述指令储存器用于储存至少一个程序的至少一部分的指令。引擎包括引擎指令缓存以及请求所述至少一个程序的所述至少一部分的子集的电路。

权利要求

1.一种处理器，包括：

指令储存器，所述指令储存器储存至少一个程序的至少一部分的指令；以及一组耦合到所述指令储存器的多个多线程引擎，所述多个多线程引擎中的单独的多线程引擎包括引擎指令缓存以及电路，所述电路响应于在所述多个多线程引擎中的至少一个上执行的所述至少一个程序中包括的取指令，请求所述至少一个程序的所述至少一部分指令的子集，其中所述取指令包括对切换到不同线程的请求，并且响应于确定所述至少一个程序的所述至少一部分指令的子集未储存在所述引擎指令缓存中，所述电路使得引擎线程停止，直到从所述指令储存器中取得所述至少一个程序的所述至少一部分指令的子集。

2.如权利要求1所述的处理器，其中

所述引擎指令缓存包括L1缓存；并且

所述指令储存器包括L2缓存。

3.如权利要求1所述的处理器，还包括耦合到第二组多个多线程引擎的第二指令储存器。

4.如权利要求1所述的处理器，其中所述取指令标识与取操作的状态相关联的信号。

5.如权利要求1所述的处理器，其中所述取指令标识所述指令储存器要缓存的量。

6.如权利要求5所述的处理器，

其中所述取指令将所述量标识为组合所述程序的多条指令的段的数目。

7.如权利要求1所述的处理器，其中所述多线程引擎包括从所述引擎指令缓存选择要牺牲的指令的电路。

8.如权利要求1所述的处理器，还包括以下至少一个：到交换结构的接口、到媒体访问控制器的接口以及到物理层设备的接口。

9.一种用于动态缓存引擎指令的方法，包括：响应于在多个多线程引擎中的至少一个上执行的至少一个程序中包括的取指令，请求由指令储存器储存的指令的子集，所述指令储存器由集成在单个管芯上的所述多个多线程引擎共享，其中所述取指令包括对切换到不同线程的请求；

在请求所述子集的所述多个多线程引擎的一个接收所述指令的子集；

将所述接收到的指令的子集存入所述多个多线程引擎中的一个多线程引擎的指令缓存，以及响应于确定所述至少一个程序的所述至少一部分指令的子集未储存在所述引擎指令缓存中，停止引擎线程，直到从所述指令储存器中取得所述至少一个程序的所述至少一部分指令的子集。

10.如权利要求9所述的方法，

其中所述指令储存器包括L2缓存；并且

其中所述多个多线程引擎中的一个多线程引擎的所述指令缓存包括L1缓存。

11.如权利要求9所述的方法，

其中所述指令储存器是一组指令储存器中的一个，所述一组指令储存器的不同指令储存器由不同的引擎组共享。

12.如权利要求9所述的方法，还包括从所述引擎指令缓存中选择要牺牲的指令。

13.如权利要求10所述的方法，还包括执行所述指令的子集以处理通过网络接收到的分组。

14.一种用于动态缓存引擎指令的装置，包括：用于响应于在多个多线程引擎中的至少一个上执行的至少一个程序中包括的取指令，请求由指令储存器储存的指令的子集的装置，所述指令储存器由集成在单个管芯上的所述多个多线程引擎共享，其中所述取指令包括对切换到不同线程的请求；

用于在请求所述子集的所述多个多线程引擎的一个接收所述指令的子集的装置；

用于将所述接收到的指令的子集存入所述多个多线程引擎中的一个多线程引擎的指令缓存的装置；以及用于响应于确定所述至少一个程序的所述至少一部分指令的子集未储存在所述引擎指令缓存中，停止引擎线程，直到从所述指令储存器中取得所述至少一个程序的所述至少一部分指令的子集的装置。

15.一种网络转发设备，包括：

交换结构件；

通过所述交换结构件互联的一组线卡，所述线卡组的至少一个包括：至少一个物理层设备；以及

至少一个网络处理器，所述网络处理器包括：

指令储存器；

可操作地耦合到所述指令储存器的一组多线程引擎，所述一组多线程引擎的单独的多线程引擎包括：用于储存指令的缓存，所述指令由所述引擎执行；以及电路，用于响应于在所述一组多线程引擎中的至少一个上执行的至少一个程序中包括的取指令，从所述指令储存器请求指令的子集，所述指令由所述指令储存器储存，所述取指令包括对切换到不同线程的请求，并且用于响应于确定所述至少一个程序的所述至少一部分指令的子集未储存在所述引擎指令缓存中，停止引擎线程，直到从所述指令储存器中取得所述至少一个程序的所述至少一部分指令的子集。

16.如权利要求15所述的网络转发设备，其中用于请求指令的所述子集的所述电路包括当在所述多线程引擎的指令缓存中未找到要被执行的指令时被调用的电路。

17.如权利要求15所述的网络转发设备，其中用于请求指令的所述子集的所述电路包括响应于由所述多线程引擎执行的指令的电路。

18.如权利要求15所述的网络转发设备，其中所述网络处理器还包括第二指令储存器；以及

可操作地耦合到所述第二指令储存器的第二组多线程引擎。

说明书

背景

网络使得计算机和其他设备能够通信。例如网络可以携带表征视频、音频、电子邮件等的数据。通常，通过网络发送的数据被划分(divide)成称为分组(packet)的更小的信息(message)。类似地，分组非常像你投入邮箱的信封。分组通常包括“有效负荷”和“头部”。分组的“有效负荷”类似于信封里的信。分组的“头部”非常像写在信封本身上的信息。头部可以包括用于帮助网络设备适当地处理分组的信息。例如，头部可以包括标识分组目的地的地址。

给定的分组可以在到达其目的地之前“跳(hop)”过许多不同的中间网络设备(例如“路由器”、“桥路器”和“交换机”)。这些中间设备通常执行多种分组处理操作。例如，中间设备通常执行操作来确定如何更进一步向其目的地转发分组或确定在处理分组中要用到的服务质量。

随着网络连接速度的增长，中间设备所具有的用于处理分组的时间量继续缩小。为了实现快速分组处理，许多设备以专用的、“硬连线”设计(例如专用集成电路(ASIC))为特征。然而，这些设计通常难以适合新兴的网络技术和通信协议。

为了将灵活性和通常与ASIC相关联的速度结合起来，一些网络设备以可编程网络处理器为特征。网络处理器使得软件工程师能够迅速地重编(reprogram)网络处理器操作。

通常，同样是由于不断增长的网络连接速度，处理分组所花费的时间大大地超过了分组到达的速率。因此，一些网络处理器的体系结构以同时处理分组的多个处理引擎为特征。例如，当一个引擎确定如何转发一个分组时，另一个引擎确定如何转发不同的一个分组。尽管处理给定分组的时间可以保持相同，同时处理多个分组使得网络处理器能够应对大量到来的分组。

附图简要说明

图1是描述网络处理器的指令缓存的图。

图2是描述用于将指令取到引擎的指令缓存中的指令操作的图。

图3是描述由网络处理器引擎执行的指令处理的流程图。

图4是描述指令缓存的流程图。

图5是描述用于搜索被缓存指令的引擎电路的图。

图6是被分配给网络处理器引擎的不同线程的指令缓存存储器的映射图(map)。

图7是网络处理器引擎图。

图8是网络处理器图。

图9是网络设备图。

详细说明

图1示出了包括多个处理引擎102的网络处理器100。引擎102可以被编程为执行各种分组处理操作，例如确定分组的下一跳、应用服务质量(Qos)，测量分组流量等等。在示出的体系结构中，引擎102执行储存在引擎102的高速本地存储器104的程序指令108。由于尺寸和成本的限制，由引擎102提供的指令存储器104的数量通常是有限的。为了防止引擎存储器104的有限的储存量(storage)对程序108的整体大小和复杂性施加过于严格的约束，图1示出了指令缓存方案的实施例，所述指令缓存方案在引擎102对程序108的执行进行时，动态地将更大的程序108的段(例如108b)下载到引擎102。

在图1中示出的实施例中，每个引擎102包括存有程序108指令的子集的指令缓存(cache)104。例如，分组引擎102a的指令缓存104a保持程序108的段108b。程序108的余下部分储存在引擎102所共享的指令储存器(instruction store)106中。

最后，引擎102a可能需要访问除段108b外的程序段。例如，程序可以分支或顺序地前进到程序108内段108b之外的点。为了使引擎102可以继续程序108的执行，网络处理器100将把所请求/所需的段下载到引擎102a的缓存104a。因此，由缓存储存的段随着程序执行的进行动态地改变。

如图1所示，多个引擎102从指令储存器106接收要缓存的指令。共享的指令储存器106可以依次缓存来自层次上更高的指令储存器110的指令，所述储存器110位于处理器的内部或外部。换句话说，指令储存器104、106和110可以形成缓存层次，所述缓存层次包括引擎的L1指令缓存104和由不同引擎共享的L2指令缓存106。

尽管图1将指令储存器106描述为服务所有的引擎102，网络处理器100可以另外以服务不同的引擎102组的多个共享的储存器106为特征。例如，一个共享的指令储存器106可以为引擎#1到#4储存程序指令，而另一个为引擎#5到#8储存程序指令。此外，尽管图1将引擎缓存104和指令储存器106描述为储存单个程序108的指令，它们可以另外储存属于不同程序的指令集。例如，共享的指令存储器106可以为每个引擎102或甚至不同的引擎102线程储存不同的程序指令。

图1将指令108描述为源代码以简化描述。由共享的储存器106储存和由引擎分发的实际指令通常会是在由引擎提供的指令集中表示(express)的可执行指令。

潜在地，引擎102所需的用于继续程序执行的程序段可以在“按需”的基础上来提供。也就是说，引擎102可以继续执行储存在指令缓存104a中的指令108b，直到在缓存104a中找不到需要执行的指令。当这种情况发生时，引擎102可以信令(signal)共享的储存器106输送包括要被执行的下一条指令的程序段。然而，这个“按需”的情形(scenario)可能将延迟引入引擎102的程序执行。也就是说，在“按需”的时序中，引擎102(或引擎102线程)可以保持空闲直到所需指令被加载。该延迟可以不仅仅由将所需的指令下载到引擎102L1缓存104所涉及到的操作引起，还可以由访问共享的储存器106的引擎102b-102n之间的竞争引起。

为了潜在地避免该延迟，图2示出了包括取指令122的程序源代码列表的一部分，所述取指令122允许程序在当指令将被要求继续程序的执行时之前，发起将程序指令“预取”到引擎的缓存104的操作。例如，如图2所示，取指令122导致引擎102n在执行进行到下一个段108b中的点之前，向共享的指令储存器106发布(“1”)请求下一个所需段108b的请求。当引擎102继续处理取指令122之后的指令124时，被请求的段被载入引擎102n的指令缓存104n。换句话说，用于取得(retrieve)(“2”)程序段的时间与在引擎执行预取指令122和引擎“用完”要在当前被缓存的程序段中执行的指令的时间之间的时间重叠。

在图2中示出的实施例中，用于取得程序指令的时间被在取指令之后执行指令122所花费的时间所隐蔽(conceal)。还可以通过在指令120(例如存储器操作)后执行取指令来“隐藏(hide)”取延迟，所述指令120花费一些时间来完成。

图2中示出的实例性取指令具有语法：

Prefetch(SegmentAddress，SegmentCount)[，optional_token]

其中，SegmentAddress标识要从共享的储存器106取得的程序的起始地址并且SegmentCount标识要取出的后续段的数目。潜在地，SegmentAddress可以被约束为标识程序段的起始地址。

optional_token具有语法：

optional_token＝[ctx_swap[signal]，][sig_done[signal]]

ctx_swap参数指示引擎102切换到另一个引擎的执行线程，直到信号指示程序段取操作完成。sig_done参数还标识一旦取操作完成即被设置的状态信号，但不指示引擎102切换上下文(context)。

在图2中示出的指令语法仅仅是示例性的，并且其他用于取出程序指令的指令可以以不同参数、关键字为特征，并且以不同选项为特征。此外，指令可以存在于不同的级别中。例如，指令可以是引擎的指令集的部分。可替换地，指令可以是由编译器处理来产生对应于取指令的目标指令(例如引擎可执行指令)的源代码指令。这样的编译器可以执行其他传统的编译器操作，例如用于将源代码的文本字符组合(group)成“单词(token)”的词法分析、将单词组合成文法短语的语法分析、更加抽象地表征源代码、优化等的中间代码生成。

取指令可以由程序员在代码开发期间手工地插入。例如，基于分组的初始分类，可以知道用于分组的剩余的程序流(flow)。因此，取指令可以在分类之后取得处理分组所需的段。例如，以高级语言编写的程序可以包括指令：

switch(classify(packet.header)){

  case DropPacket:{

    prefetch(DropCounterInstructions)；

}

  case ForwardPacket{

    prefetch(RountingLookupInstructions)

    prefetch(PacketEnqueueInstructions)；

}}

所述指令基于分组的分类将适当的程序段载入引擎102的指令缓存104。

尽管程序员可以手工地将取指令插入代码，取指令还可以由软件开发工具，例如编译器、分析器、剖析器(profiler)和/或预处理器插入到代码中。例如，代码流分析可以标识不同的程序段何时应该被加载。例如，编译器可以在存储器访问指令之后或在一组要花费一些时间来执行的指令之前插入取指令。

图3示出了流程图，所述流程图图示“按需”和响应于“取”指令来取得指令的引擎的操作。如图3所示，标识下一条要执行的程序指令的程序计数器130被更新。例如，程序计数器130可以被递增，以前进到下一个顺续的指令地址，或计数器130可以响应于分支指令，被设置为一些其他的指令地址。如图所示，引擎确定132是否引擎的指令缓存目前保持程序计数器所标识的指令。如果没有，引擎线程停止(stall)134(例如，需要指令的线程被交换出引擎)，直到取操作136从共享的储存器取得未命中的指令。

一旦要被执行的指令存在于引擎的指令缓存中，引擎可以确定140是否下一条要执行的指令是取指令。如果是，引擎可以发起被请求的程序段的取操作142。如果不是，引擎可以照常处理144指令。

图4示出了共享的指令缓存106的实例性的体系结构。例如，在网络处理器启动期间，指令缓存106接收指令(“1”)以与引擎共享。之后，共享的指令缓存106按照所需和/或所请求的，将指令108的部分分发(distribute)到引擎。

如图4的实例性体系结构所示，两条不同的总线150、152可以将共享的缓存106连接到引擎102。总线150携带(“2”)对共享的缓存106的取请求。这些请求可以标识要取出的程序段108和做出请求的引擎。请求还可以标识该请求是预取操作还是“按需”取操作。高带宽总线152将被请求的程序段中的指令传送(carry)(“4”)回请求引擎102。总线152的带宽可以允许共享的缓存106同时将所请求的指令传输到多个引擎。例如，总线152可以被划分成可以被动态分配给引擎的n条线路(line)。例如，如果4个引擎请求段，每个可以被分配给25％的总线带宽。

如图所示，共享的缓存106可以在请求到达时(例如，在用于后续服务的(先进先出)FIFO队列154中)对他们进行排队。然而，如上所述，当要被执行的指令还未被加载到引擎的指令缓存104中时，该线程停止。因此，服务导致实际停止的“按需”请求比服务可能导致或可能不导致停止的“预取”请求呈现出更加紧迫的重要性。如图所示，共享的缓存106包括判优器(arbiter)156，所述判优器156可以授予需求请求(demand request)高于(over)预取请求的优先权。判优器156可以包括专用电路或者可以是可编程的。

判优器156可以以各种方式区分需求请求的优先权。例如，判优器156可以不把需求请求添加到队列154，但可以另外将所述请求表示为立即服务(“3”)。为了区分多个“需求”请求之间的优先权，判优器156还可以维持一个独立的“需求”FIFO队列，所述“需求”FIFO队列由判优器156授予高于FIFO队列154中的请求的优先权。判优器156还可以立即挂起正在进行的指令下载操作以服务需求请求。此外，判优器156可以分配很大一部分(不然的话100％)的总线152带宽，以将段指令传递到发布“按需”请求的引擎。

图5示出了引擎的指令缓存的实例性的体系结构。如图所示，缓存储存由一组存储器设备166x来提供，所述存储器设备166x储存通过总线164从共享的指令储存器106接收的指令。可以将单独的存储器元件166a的大小调整为保持一个程序段。如图所示，每个存储器166x与地址译码器相关联，所述地址译码器从引擎接收要被处理的指令的地址并且确定该指令是否存在于相关联的存储器166中。不同的译码器并行地对地址进行操作。也就是说，每个译码器同时搜索自身相关联的存储器。如果在存储器166x中的一个存储器中找到指令地址，那么那个存储器166x单元输出168要被引擎处理的所请求的指令。如果在存储器166的任何一个存储器中都未找到指令地址，那么产生“未命中”信号168。

如上所述，引擎可以提供多个执行线程。在执行的过程中，这些不同的线程将把不同的程序段载入引擎的指令缓存。当缓存被填满时，将段载入缓存的操作需要一些其他段从缓存中被移除(“牺牲”)。没有一些安全措施，线程可能牺牲当前正被另一个线程使用的段。当其他线程恢复处理时，最近牺牲的段可以再次从共享的缓存106中取出。这种指令缓存104的线程间颠簸(inter-thread thrashing)可能不断地重复，显著降低了系统性能，因为刚被一个线程载入缓存的段，却过早地被另一个线程牺牲，并且在短时间后被重新加载。

为了抵抗这样的颠簸，各种机制可以在线程牺牲段的能力上施加限制。例如，图6示出了引擎的指令缓存104的存储器映射图，其中给每个引擎线程分配独占的一部分缓存104。例如，给线程0172分配了用于N个程序段172a、172b、172n的存储器。为线程取出的指令段可以驻留在线程的缓存104的分配空间中。为了防止颠簸，逻辑可以限制一个线程牺牲来自分配给其他线程的缓存分区的段。

为了快速访问被缓存的段，与线程相关联的控制和状态寄存器(CSR)可以储存已分配缓存部分的起始地址。该地址可以，例如基于线程编号(number of threads)来计算(例如，分配空间起始地址＝基址+(线程#X每个线程分配的存储器))。每个分区可以进一步划分成段，所述段例如对应于从共享的储存器106的突发(burst)取大小或其他的从共享的储存器106到引擎缓存的传输粒度。可以为不同的段在线程的已分配缓存部分中维持LRU(最近最少使用的)信息。因此，在LRU方案中，可以首先牺牲给定线程的缓存中最近最少使用的段。

除了在不同线程之间被划分的区域之外，示出的映射图还包括“锁住(lock-down)”部分170。在锁住区域中的指令可在初始化时被加载，并且可以被保护以免牺牲。所有线程可以访问和执行储存在该区域的指令。

例如图6中示出的方案的存储器分配方案可以阻止线程间颠簸。然而，还可以使用其他的方法。例如，访问计数可以与当前正在使用段的线程相关联。当计数到达零时，可以牺牲所述段。可替换地，缓存牺牲方案可以应用不同的规则。例如，所述方案可以试图避免牺牲还未被任何线程访问过的已加载段。

图7示出了实例性的引擎102体系结构。引擎102可以是为分组处理定制的精简指令集计算(RISC)处理器。例如，引擎102可以不提供通用处理器的指令集通常提供的浮点或整数除法指令。

引擎102可以通过传输寄存器192a、192b与其他网络处理器部件(component)(例如共享的存储器)通信，所述传输寄存器192a、192b缓冲要发送到其他部件/从其他部件接收到的数据。引擎102还可以通过硬连线到其他引擎的“邻居”寄存器194a、194b与其他引擎102通信。

示出的实例性的引擎102提供多个执行线程。为了支持多个线程，引擎102为每个线程储存程序上下文182。该上下文182可以包括线程状态数据例如程序计数器。线程判优器180选择要执行的线程的程序上下文182x。用于被选中的上下文的程序计数器被传送到指令缓冲104。当程序计数器标识的指令当前未被缓存时(例如，段未在锁住的缓冲区域或未在被分配给当前执行线程的区域中)，缓冲104可以发起程序段取操作。否则，缓冲104将被缓存指令发送到指令译码单元186。潜在地，指令译码单元190将指令标识为“取”指令并且发起段的取操作。否则，译码190单元可以使指令传送到执行单元(例如ALU)以便处理，或通过命令队列188发起对不同引擎所共享的资源(例如存储器控制器)的请求。

取控制单元184处理从共享的缓存106取得程序段的操作。例如，取控制单元184可以协商对共享的缓存请求总线的访问、发布请求和将被返回的指令存入指令缓存104。取控制单元184还可以处理先前被缓存的指令的牺牲。

引擎102的指令缓存104和译码器186形成指令处理流水线的部分。也就是说，在多个时钟周期的过程中，指令可以从缓存104，、译码器186加载，可以是加载的指令操作数(例如，从通用寄存器196、下一个邻居寄存器194a、传输寄存器192a和本地存储器198)，并且可以由执行数据通路190执行。最后，操作的结果可以被写入(例如，写到通用寄存器196、本地存储器198、下一个邻居寄存器194b或传输寄存器192b)。在流水线中可以同时有许多指令。也就是说，当一条指令正被译码时，另一条正从L1指令缓存104被加载。

图8示出了网络处理器200的实施例。示出的网路处理器200是互联网交换网路处理器(IXP)。其他网络处理器以不同的设计为特征。

示出的网络处理器200以集成在单个管芯上的一组分组引擎102为特征。如上所述，单独的分组引擎102可以提供多个线程。处理器200还可以包括核心处理器210(例如强大的)，所述核心处理器210通常被编程为执行网络操作涉及到的“控制面(control plane)”任务。然而，核心处理器210还可以处理“数据面(data plane)”任务并且可以提供额外的分组处理线程。

如图所示，网络处理器200还以接口202为特征，所述接口202可以在处理器200和其他网络部件之间传送分组。例如，处理器200可以以交换结构接口202(例如通用交换接口(CSIX)接口)为特征，所述交换结构接口202使得处理器200能够将分组传输到连接到该结构的其他处理器或电路。处理器200还可以以接口202(例如系统分组接口(SPI)接口)为特征，所述接口202使得处理器能够与物理层(PHY)和/或链路层设备通信。处理器200还可以包括接口208(例如外设部件互联(PCI)总线接口)以便例如与主机通信。如图所示，处理器200还可以包括由引擎共享的其他部件，例如存储器控制器206、212、哈希引擎和便笺式存储器。

以上所述的分组处理技术可以在例如IXP的网络处理器上以各种各样的方式实现。例如，核心处理器210可以在网络处理器引导期间将程序指令输送到共享的指令缓存106。此外，不同于“深度为2(two-deep)”的指令缓存层次，例如，当处理器以大量的引擎为特征时，处理器200可以以深度为N(N-deep)的指令缓存层次为特征。

图9示出了包括以上描述的技术的网络设备。如图所示，设备以一组通过交换结构310(例如纵横结构或共享的存储器交换结构)互连的线卡(“刀片(blade)”)为特征。交换结构例如可以遵守CSIX或其他结构技术，例如HyperTansport、Infiniband、外设部件互联Express(PCI-X)等。

单独的线卡(例如300a)可以包括一个或更多个处理网络连接上的通信的物理层(PHY)设备302(例如光、有线和无线的物理层)。PHY在不同网络介质携带的物理信号和数字系统所使用的位(例如“0”和“1”)之间翻译。线卡300可以包括(例如以太网、铜鼓光网络(SONET)、高级数据链路)。线卡300还可以包括成帧器设备(例如，以太网、同步光网络(SONET)、高级数据链路(HDLC)成帧器或其他的“层2”设备)304，所述设备可以对帧执行例如检错和/或纠错的操作。示出的线卡300还可以包括一个或更多个使用上述的指令缓存技术的网络处理器306。网络处理器306被编程为对通过PHY 300接收到的分组执行分组处理操作，并且通过交换结构310将分组导向到提供被选中的出口接口的线卡。潜在地，网络处理器306可以代替成帧器设备304来履行“层2”的职责。

尽管在图8和图9中示出了引擎、网络处理器和包括网络处理器的设备的实例性体系结构，可以在其他引擎、网络处理器和设备设计中实现这些技术。此外，可以在各种网络设备(例如，路由器、交换机、桥路器、集线器、流量发生器等)中使用这些技术。

本文用到的术语电路包括硬连线电路、数字电路、模拟电路、可编程电路等。可编程电路可以在计算机程序上运行。

这样的计算机程序可以以高级过程或面向对象编程语言来编码。然而，如果需要，可以以汇编或机器语言实现所述程序。语言可以被编译或解释。此外，可以在各种联网环境中使用这些技术。

其他实施方案在所附权利要求书的范围之内。

相关申请引用：本申请和以下与本申请在同一天递交的申请相关：

a.律师案卷号P16851-“Service Engine Cache Request(服务引擎缓存请求)”

b.律师案卷号P16852-“Thread-Based Engine Cache Partitioning(基于线程的引擎缓存分区)”