专利名称：一种加速硬件加解密处理方法、装置和设备的制作方法
技术领域：
本发明实施例涉及一种加速硬件加解密处理方法、装置和设备，属于数据通信技 术领域。
背景技术：
嵌入式系统是一种以应用为中心、以计算机技术为基础、软件硬件可裁剪、适应应 用系统，对功能、可靠性、成本、体积、功耗严格要求的专用计算机系统。嵌入式系统是将先 进的计算机技术、半导体技术、电子技术和各个行业的具体应用相结合后的产物，嵌入式计 算机的外部设备中就包含了多个嵌入式微处理器，如键盘、硬盘、显示器、网卡、声卡等均是 由嵌入式处理器控制的。在嵌入式系统里，由于成本和性能因素，系统的资源是很有限的，中央处理单元 (Central Processing Unit，简称CPU)计算性能作为系统重要的资源，各处理模块不能大 量占用，否则影响到系统中另外功能模块正常运行。硬件加解密处理由于实现的算法运算 量大，加解密处理在嵌入式系统里会占用较多的CPU资源。如果处理不当，会造成整个系统 性能下降。这里首先对硬件加解密处理的流程和架构进行简单的介绍。例如现在主流的因特网协议安全(Internet Protocol Security，简称IPsec)加 解密处理方案都不再采用软件模式，因为加解密算法涉及到的运算量非常大，软件运行加 解密算法会消耗大量的CPU资源，同时处理效率得不到保证，所以现在几乎所有加解密方 案都是采用硬件加解密处理模块完成对实际的加解密算法的运算，具体的加解密方案的流 程和架构可以参见图1，加解密驱动模块接收数据层面的加解密需求，将其下发的待处理数 据送入硬件加解密处理模块进行加解密处理，并根据数据层面下发的相关参数对硬件加解 密处理模块进行配置；此外，加解密驱动模块从硬件加解密处理模块中取得处理完成的数 据，送回到数据层面。加解密驱动模块具体又可以分为加解密驱动初始化模块、加解密驱动数据传入模 块和加解密驱动数据回送模块，如图2所示。加解密驱动初始化模块在整个系统初始化时运行，完成对硬件加解密处理模块的 复位和配置操作。加解密驱动数据传入模块是一个被动运行的程序模块，该模块提供一个函数接口 供数据层面的函数调用，当数据层面主动发起加密或解密请求时，就调用该函数接口，将需 要加密或解密的数据及相关参数送入加解密驱动数据传入模块，该模块会根据相关参数对 硬件加解密处理模块进行配置，然后将数据送入其中进行处理；硬件加解密处理模块完成 对数据的加解密运算后，将处理完成的数据放入指定的地址中，等待加解密驱动数据回送 模块将数据取回送交数据层面，此时通常有两种做法，一种是中断处理方式，一种是查询处 理方式。中断处理方式就是在硬件加解密处理模块完成对应的加解密操作后，产生中断，通知CPU数据已处理完成，CPU接收到中断，再调用中断处理程序，即调用加解密驱动数据 回送模块对应的程序接口，将处理完成的数据送回数据层面，完成一次处理。中断处理方式 在每个包处理结束后都会产生中断，如果有大量数据包要进行加解密处理，CPU就会频繁中 断，占用大量的处理资源，因此会影响到系统中其它模块处理，使得整个系统性能下降。查询处理方式就是屏蔽硬件加解密处理模块产生的中断，保证CPU不会再因为中 断而打断当前的运行流程，这种情况下硬件加解密处理模块完成加解密处理后会将相应的 硬件旗标置位，以此告知数据处理完成，等待加解密驱动数据回送模块将处理完成的数据 包取走。硬件旗标为硬件某个寄存器中的一个标志flag字段，当完成加解密处理后，硬件 会将这个flag字段置位，表示硬件已经完成对数据的加解密处理。查询处理方式通过定时 器进行定期查询，由定时器触发对硬件旗标进行一定时间间隔的查询，当查询到存在加解 密完成的数据包时就调用加解密驱动数据回送模块对应的程序接口将数据包送交数据层 面，然后重启定时器，开始等待下一次的查询。这种处理方式的不足在于如果系统在没有数 据进行加解密处理，或处理数据较少时，定时器仍会不停地对硬件旗标进行轮询，这样就会 白白浪费CPU资源，使整个系统的CPU利用率降低。
发明内容
本发明实施例的目的是提供一种加速硬件加解密处理方法、装置和设备，用于解 决现有硬件加解密方案无法进行灵活处理，导致系统整体性能低下的问题。为实现上述目的，本发明实施例提供了一种加速硬件加解密处理方法，所述方法 包括在中断处理模式下，硬件加解密处理完成后产生中断，并由中断触发进入查询处 理模式；在查询处理模式下，定期查询是否有硬件加解密处理完成的数据包，如果有则将 所述处理完成的数据包送回数据层面，否则根据查询结果确定是否进入中断处理模式。为了实现上述目的，本发明实施例还提供了 一种加速硬件加解密处理装置，所述 装置包括硬件加解密处理模块、中断触发模块、定期查询模块、加解密驱动模块和查询结果 处理模块；所述硬件加解密处理模块用于进行数据包的加解密处理，并在中断处理模式下完 成加解密处理后产生中断；所述中断触发模块与硬件加解密处理模块连接，用于由中断触发进入查询处理模 式；所述定期查询模块与中断触发模块连接，用于在查询处理模式下，定期查询是否 有硬件加解密处理完成的数据包，如果有则通过加解密驱动模块进行处理，否则通过查询 结果处理模块进行处理；所述加解密驱动模块与硬件加解密处理模块和定期查询模块连接，用于将硬件加 解密处理完成的数据包送回数据层面；所述查询结果处理模块与定期查询模块连接，用于根据查询结果确定是否进入中 断处理模式。 为了实现上述目的，本发明实施例又提供了 一种设备，所述设备包括上述装置。
本发明实施例通过采用中断和查询相结合的方式，在硬件加解密处理完成后通过 中断来触发查询过程，并通过对查询结果的判断来决定是否进入中断处理模式，依靠中断 处理模式保证了对数据处理的实时性，依靠查询处理模式提高硬件加解密的处理速度，凭 借两种处理方式的结合，从一定程度上解决了纯中断处理方式或纯查询处理方式带来的硬 件加解密处理整体性能低下的问题，同时使CPU资源利用更加高效。
图1为现有技术中硬件加解密处理流程实施例一示意2为现有技术中硬件加解密处理流程实施例二示意3为本发明一种加速硬件加解密处理方法实施例一示意4为本发明一种加速硬件加解密处理方法实施例二示意5为本发明一种加速硬件加解密处理方法实施例三示意6为本发明一种加速硬件加解密处理方法实施例四示意7为本发明一种加速硬件加解密处理方法实施例五示意8为本发明一种加速硬件加解密处理装置实施例一示意9为本发明一种设备实施例示意图
具体实施例方式本发明的目的是提供一种加速硬件加解密处理方法、装置和设备，用于解决现有 硬件加解密方案无法进行灵活处理，导致系统整体性能低下的问题。下面结合附图对本发明实施例进行说明，本发明实施例提供了一种加速硬件加解 密处理方法，图3给出了本发明一种加速硬件加解密处理方法实施例一示意图，所述方法 包括步骤Si，在中断处理模式下，硬件加解密处理完成后产生中断，并由中断触发进入 查询处理模式；硬件加解密处理可以由硬件加解密处理模块完成。步骤S2，在查询处理模式下，定期查询是否有硬件加解密处理完成的数据包，如果 有则将所述处理完成的数据包送回数据层面，否则根据查询结果确定是否进入中断处理模 式。本发明实施例通过采用中断和查询相结合的方式，在硬件加解密处理完成后通过 中断来触发查询过程，并通过对查询结果的判断来决定是否进入中断处理模式，依靠中断 处理模式保证了对数据处理的实时性，依靠查询处理模式提高硬件加解密的处理速度，凭 借两种处理方式的结合，从一定程度上解决了纯中断处理方式或纯查询处理方式带来的硬 件加解密处理整体性能低下的问题，同时使CPU资源利用更加高效。图4给出了本发明一种加速硬件加解密处理方法实施例二示意图，本实施例除了 包括方法实施例一的步骤外，所述根据查询结果确定是否进入中断处理模式具体可以为 如果满足一次或多次查询无处理完成的数据包的条件，则进入中断处理模式，否则保持查 询处理模式。例如可以在第一次查询到无处理完成的数据包时，即进入中断处理模式，等待硬件加解密处理完成后产生中断来触发查询过程；这种方式可以使得在没有数据需要处理时 及时进入中断处理模式，较为及时地节省系统资源。也可以在第一次查询到无处理完成的数据包时，暂时不进入中断处理模式，而是 继续进行定期查询，直至连续N次查询均无处理完成的数据包时，才进入中断处理模式。例 如批量到来的数据包在进行硬件加解密处理的过程中，可能由于网络故障或其它原因导致 处理数据包的短暂的中断，因而导致某次查询结果为无处理完成的数据包，但是后续数据 包很快到达并继续进行加解密处理，通过连续N次查询的处理方式，使得硬件加解密的处 理仍然停留在查询处理模式下，不会因为短暂的数据包中断而切换入中断处理方式，这样 就能够保证数据流在出现短暂中断后又重新恢复的情况下，系统依然能够运行在高效的查 询处理模式下，从宏观上提供一种“消抖”的处理策略。由于查询的开销远小于中断的开销， 因此这种方式将会节省系统开销。图5给出了本发明一种加速硬件加解密处理方法实施例三示意图，本实施例除了 包括方法实施例二的步骤外，步骤Sl中所述由中断触发进入查询处理模式具体可以为关闭中断，并启动定时 器进行定期查询。步骤S2中所述将所述处理完成的数据包送回数据层面之后还包括重启定时器， 在下一时间点继续进行查询操作。步骤S2中所述进入中断处理模式具体可以为打开中断，并终止定时器。本实施例除了可以在方法实施例二的基础上进行上述扩展外，还可以在方法实施 例一的基础上进行上述扩展。图6给出了本发明一种加速硬件加解密处理方法实施例四示意图，本实施例除了 包括方法实施例三的步骤外，在步骤S2之前还包括步骤S3，初始时进入中断处理模式。初始时进入中断处理模式使得系统在初始状态时即处于不消耗系统CPU资源的 状态下，只有在有硬件加解密处理完成的数据时才会触发中断，随后进入查询处理模式，合 理地利用并节省了系统资源。本实施例除了可以在方法实施例三的基础上进行上述扩展外，还可以在方法实施 例一或方法实施例二的基础上进行上述扩展。图7给出了本发明一种较优实施例，本实施例步骤如下步骤101，初始时进入中断处理模式；步骤102，完成数据的硬件加解密处理后，产生中断，由中断触发查询过程，关闭中 断并且启动定时器；步骤103，进入查询处理模式，对硬件加解密处理结果进行查询；步骤104，在查询处理过程中，如果查询到本查询周期内有硬件加解密处理完成的 数据包时，则执行步骤105，否则执行步骤106 ；步骤105，将处理完的数据送回数据层面，并重启定时器，在下一时间点继续进行 查询操作，执行步骤103;步骤106，终止定时器，打开中断，回到中断处理模式，执行步骤102。从上图可以看出，查询处理过程依赖于中断的触发，如果有连续的加解密完成的 数据输出，则中断处理仅仅在第一个数据输出时产生，随后查询处理过程可以有效接手后续的处理，提供高效的数据回送到数据层面的处理，且一旦所有数据已经回送完毕，查询处理在下一个查询周期发现不再有加解密完成的数据时，就会终止查询过程，打开中断，等待 以后某个时间点再次产生的新的加解密处理完成的数据，从而避免了长时间没有加解密处 理数据的情况下，查询模式空转造成CPU资源浪费。中断处理方式和本发明实施例方案性能比较如下由于加解密处理性能、中断切换性能都与系统时钟有关，所以使用相同系统下的 数据进行对比。硬件加解密所花费的时间由于其算法不同而有较大差异，以某款交换机对 高级加密标准(Advanced Encryption Standard，简称AES)算法的测试数据为例，确定系统 条件如下硬件加解密处理完成一个包需要6. 67us (微秒，千分之一毫秒)，中断切换时间为 0. 5us，定时器启动占用时间为5ns (纳秒，千分之一微秒)，默认对处理1000个数据包的效 率进行比较。使用中断处理方式时，处理1000个数据包所需时间为(1000 个)*(6.67us/个)+ (1000 个)*(0.5us/个)=7170us在本发明的方案中，设定时器Timer的时间间隔设置为lOOOus，则Timer在每个时 间间隔内可以处理1000/6. 67 = 150个包，但仅第一个包会产生一次中断，查询次数为150 次，因此本发明实施例方案处理1000个数据包所需时间为(1000 个)*(6. 67us/ 个)+0. 5u s+150*5ns = 6671. 25us本发明实施例方案比中断处理方式性能提高了(7170-6671. 25)/6671. 25*100% =7. 48%查询处理方式和本发明实施例方案性能比较如下本发明实施例方案对比查询处理方式的优势在于能够实时的自动识别当前的加 解密处理情况，根据加解密处理结果自动调整查询操作的停止和启动，提高了数据处理的 及时性。且在系统长时间没有加解密数据进行处理时，本发明方案对系统资源的消耗为零， 而对比查询处理方式持续运行的定时器开销，本方案在CPU资源利用率上的优势非常明
Mo仍然采用与中断处理方式比较时使用的系统条件，在没有任何数据时，本发明 实施例方案处于中断处理模式，由于没有数据，因此不发生中断，没有系统开销，如果每 IOOOus查询一次，则在1秒钟内，查询处理方式需要查询1000次，每次花费的定时器的启动 时间是5ns，每秒钟花费在启动定时器上的额外开销为5ns*1000 = 5ms,即资源浪费率达到 千分之五。如果用户没有使用加解密功能，则采用查询处理方式会导致系统在一天当中有 7分多钟(5ms*60*60*24 = 432秒)的时间，系统是处于毫无回报的资源浪费状态中，因为 在启动定时器时，系统是无法处理其他业务的。由此可见，本发明实施例方案对比查询处理 方式的优势还在于对CPU资源的合理利用上，能够实时根据业务需求对CPU资源进行合理 的分配和利用。本发明实施例方案非常适合CPU资源有限，但是对加解密速度有一定需求的系 统，本发明实施例方案能够在需要处理数据的时候提供比中断处理方式更为高效的查询处 理模式，同时也能在没有数据处理的时候马上退出查询处理模式，保证有限的CPU资源能 够尽快释放，而不被不必要的轮询所占用。
本发明实施例还提供了一种加速硬件加解密处理装置，图8给出了本发明一种加 速硬件加解密处理装置实施例一示意图，所述装置包括硬件加解密处理模块Ml、中断触发 模块M2、定期查询模块M3、加解密驱动模块M4和查询结果处理模块M5 ；所述硬件加解密处理模块Ml用于进行数据包的加解密处理，并在中断处理模式 下完成加解密处理后产生中断；所述中断触发模块M2与硬件加解密处理模块Ml连接，用于由中断触发进入查询 处理模式；所述中断触发模块具体可以用于关闭中断，并启动定时器进行定期查询。
所述定期查询模块M3与中断触发模块M2连接，用于在查询处理模式下，定期查询 是否有硬件加解密处理完成的数据包，如果有则通过加解密驱动模块M4进行处理，否则通 过查询结果处理模块M5进行处理；所述定期查询模块还可以用于在通过加解密驱动模块进行处理之后，重启定时 器，在下一时间点继续进行查询操作。所述加解密驱动模块M4与硬件加解密处理模块Ml和定期查询模块M3连接，用于 将硬件加解密处理完成的数据包送回数据层面；所述加解密驱动模块还可以用于将需要加密或解密的数据送入硬件加解密处理 模块。所述查询结果处理模块M5与定期查询模块M3连接，用于根据查询结果确定是否 进入中断处理模式。所述查询结果处理模块具体可以用于确定是否满足一次或多次查询无处理完成 的数据包的条件，是则进入中断处理模式，否则保持查询处理模式。所述进入中断处理模式具体可以为打开中断，并终止定时器。本发明实施例又提供了一种设备，图9给出了本发明一种设备实施例示意图，所 述设备包括上述加速硬件加解密处理装置实施例所述的任一装置。所述设备可以为具有加解密功能的交换机或路由器等设备，例如具有IPsec加解 密功能的交换机或路由器。最后应说明的是以上实施例仅用以说明本发明的技术方案，而非对其限制；尽 管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解其依然 可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替 换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精 神和范围。
权利要求
一种加速硬件加解密处理方法，其特征在于，所述方法包括在中断处理模式下，硬件加解密处理完成后产生中断，并由中断触发进入查询处理模式；在查询处理模式下，定期查询是否有硬件加解密处理完成的数据包，如果有则将所述处理完成的数据包送回数据层面，否则根据查询结果确定是否进入中断处理模式。
2.根据权利要求1所述的方法，其特征在于，所述根据查询结果确定是否进入中断处 理模式具体为如果满足一次或多次查询无处理完成的数据包的条件，则进入中断处理模 式，否则保持查询处理模式。
3.根据权利要求1或2所述的方法，其特征在于，所述由中断触发进入查询处理模式具 体为关闭中断，并启动定时器进行定期查询。
4.根据权利要求3所述的方法，其特征在于，所述将所述处理完成的数据包送回数据 层面之后还包括重启定时器，在下一时间点继续进行查询操作。
5.根据权利要求3所述的方法，其特征在于，所述进入中断处理模式具体为打开中 断，并终止定时器。
6.根据权利要求1或2所述的方法，其特征在于，所述方法还包括初始时进入中断处理模式。
7.一种加速硬件加解密处理装置，其特征在于，所述装置包括硬件加解密处理模块、中 断触发模块、定期查询模块、加解密驱动模块和查询结果处理模块；所述硬件加解密处理模块用于进行数据包的加解密处理，并在中断处理模式下完成加 解密处理后产生中断；所述中断触发模块与硬件加解密处理模块连接，用于由中断触发进入查询处理模式； 所述定期查询模块与中断触发模块连接，用于在查询处理模式下，定期查询是否有硬 件加解密处理完成的数据包，如果有则通过加解密驱动模块进行处理，否则通过查询结果 处理模块进行处理；所述加解密驱动模块与硬件加解密处理模块和定期查询模块连接，用于将硬件加解密 处理完成的数据包送回数据层面；所述查询结果处理模块与定期查询模块连接，用于根据查询结果确定是否进入中断处 理模式。
8.根据权利要求7所述的装置，其特征在于，所述查询结果处理模块具体用于确定是 否满足一次或多次查询无处理完成的数据包的条件，是则进入中断处理模式，否则保持查 询处理模式。
9.根据权利要求7或8所述的装置，其特征在于，所述中断触发模块具体用于关闭中 断，并启动定时器进行定期查询。
10.根据权利要求9所述的装置，其特征在于，所述定期查询模块还用于在通过加解密 驱动模块进行处理之后，重启定时器，在下一时间点继续进行查询操作。
11.根据权利要求9所述的装置，其特征在于，所述查询结果处理模块具体用于根据 查询结果确定是否打开中断并终止定时器。
12.一种包括权利要求7-11任一所述装置的设备。
全文摘要
本发明实施例提供了一种加速硬件加解密处理方法、装置和设备。所述方法包括在中断处理模式下，硬件加解密处理完成后产生中断，并由中断触发进入查询处理模式；在查询处理模式下，定期查询是否有硬件加解密处理完成的数据包，如果有则将所述处理完成的数据包送回数据层面，否则根据查询结果确定是否进入中断处理模式。本发明实施例依靠中断处理模式保证了对数据处理的实时性，依靠查询处理模式提高硬件加解密的处理速度，凭借两种处理方式的结合，从一定程度上解决了纯中断处理方式或纯查询处理方式带来的硬件加解密处理整体性能低下的问题，同时使CPU资源利用更加高效。
文档编号H04L29/06GK101876955SQ20091023801
公开日2010年11月3日 申请日期2009年11月23日 优先权日2009年11月23日
发明者杨大川, 谭英德 申请人:北京星网锐捷网络技术有限公司