CODE COURSE NAME UNITS CREDIT

4.4.1 Introducci´on

Las GPUs actuales requieren realizar una copia de memoria desde el Host hasta la GPU para poder trabajar. Dicha copia se realiza a trav´es del puerto PCIe. Para obtener un buen rendi- miento mediante PCIe se deben utilizar pocas y grandes copias de memoria en vez de muchas y peque˜nas copias. Este suceso se produce por el coste que conlleva reprogramar sucesivamente una DMA, as´ı como el propio funcionamiento del puerto PCIe. La construcci´on de un buffer de flujos resulta necesaria para poder minimizar los costes de transferencia a la GPU.

En esta secci´on se explica la interfaz creada ente la GPU y el constructor de flujos para procesar un bloque de paquetes.

4.4.2 Implementaci´on

El m´odulo implementado ofrece una API por la cual requiere una inicializaci´on y configuraci´on. La API construida incluye una funci´on por la cual el m´odulo es informado de un nuevo flujo exportado. A partir de este punto, se procede a almacenar el flujo en memoria dentro de un buffer. No obstante, debido a la implementaci´on del m´odulo clasificador, no basta con un ´uni- co buffer sino que es requerido un conjunto fijo de buffers (ver secci´on 4.5 para m´as informaci´on). Para solucionar el problema de los m´ultiples buffers se plantea un anillo como estructura de datos de almacenamiento. En esta estructura se mantendr´a un buffer activo en donde se escribir´an los nuevos flujos entrantes. Al llenar el buffer activo, se informar´a a la GPU de que un nuevo buffer est´a listo. En ese momento el buffer activo ser´a marcado como ocupado, y el siguiente buffer del anillo se marcar´a como el nuevo buffer activo. Simult´aneamente, la GPU informar´a al terminar de utilizar un buffer. Por el funcionamiento del m´odulo de clasificaci´on, la GPU copia los resultados de la clasificaci´on en el buffer que conten´ıa los flujos originales. Es por tanto, tarea de este m´odulo, utilizar los resultados antes de marcar el buffer como libre y reutilizarlo. En la sonda realizada, el m´odulo guarda en disco los resultados para una posterior verificaci´on. Sin embargo, es importante tener en cuenta que se podr´ıan realizar diferentes ac- ciones, como pipes o la propia red, para informar a un dispositivo acerca del tr´afico del enlace. (Fig. 4.12).

A pesar de todo, puede sufrirse un degradamiento del rendimiento debido a la transferencia de memoria entre el Host y la GPU. Para resolver este problema, CUDA ofrece los conocidos streams. Un stream de CUDA, puede transferir memoria en paralelo mientras se ejecuta c´odigo tanto en el Host como en la GPU. Esto es posible gracias al dispositivo DMA, ofreciendo un mejor rendimiento al sistema. A pesar del buen rendimiento ofrecido, los CUDA streams poseen ciertos requisitos. El m´as importante radica en la memoria del Host. Los flujos retransmitidos deben encontrarse contiguos en memoria especial. Esta memoria es conocida como page-locked memory o pinned memory. Para obtener dicha memoria se ha optado por la utilizaci´on de las Hugepages ofrecidas por la API de Intel DPDK. Su utilizaci´on rompe el esquema de indepen- dencia entre m´odulos planteada inicialmente, sin embargo, se ha considerado que la utilizaci´on de dicha memoria supone un rendimiento y simplicidad superior a la memoria ofrecida por la API de CUDA cuyo uso tambi´en romper´ıa la independencia modular.

Clasificaci´on de flujos en 10G ethernet mediante Intel DPDK y GPUs

export_flow

Se copia el payload

dentro del buffer Retornar

Hay espacio disponible

Clasificación dentro de la GPU Se envía al módulo GPU un bloque de flujos El buffer está lleno Se almacenan los resultados en Disco o tmpfs Se obtiene el buffer actual desde el anillo

Figura 4.12: Exportando flujos a la GPU : Comunicaci´on con la GPU

Independientemente de la fuente de la memoria utilizada, existe un problema. La forma mas eficiente de gestionar un buffer es mediante punteros a cada flujo exportado. No obstante, la condici´on de flujos contiguos en memoria implica que la implementaci´on mencionada no sea viable. Por ello, se debe reservar gran cantidad de memoria por cada buffer y realizar numerosas copias de flujos al mismo. Aunque la implementaci´on del m´odulo resulta sencilla, es importante tener en cuenta el coste que estas copias pueden conllevar al rendimiento global de la sonda.

4.4.3 Pruebas y resultados

Debido a la simplicidad del m´odulo y a su dependencia con el resto de m´odulos, solo se han realizado pruebas de validaci´on, ya que medir el rendimiento del mismo de forma unitaria re- sulta dif´ıcil. Medir este rendimiento impondr´ıa, a su vez, un coste computacional adicional a la sonda. Tras la integraci´on no ha detectado un coste computacional significativo frente al resto de m´odulos. El funcionamiento del m´odulo ha sido verificado.

4.4.4 Conclusiones

La construcci´on del modulo de buffering ha sido esencial en la integraci´on entre los m´odulos de clasificaci´on y construcci´on de flujos. Este hecho ha impedido en gran medida cumplir con los requisitos generales de independencias entre m´odulos. En cambio, las decisiones tomadas en la construcci´on del m´odulo han sido enfocadas de forma casi exclusiva a una optimizaci´on del rendimiento.

Una vez comprendido el m´odulo de buffering y su utilidad, es posible centrarse en el m´odulo clasificador y en su arquitectura. Ambos se presentan y explican en la siguiente secci´on.