[P4] L2 gyorsulás

[Sándor Laki]

Hi,

Ez baromi jó! Jól értem, hogy ez egy core-ral a L2 P4 példával lett elérve?
A 40 Gbps esetén 1 ilyen kártya tudja ezt, vagy 4x10Gbps pl. bondolva? 
Én inkább az utóbbira gondolok...

Üdv.
Sanyi

On 2016.03.11. 12:08, Kitlei Róbert wrote:
>
> Sziasztok!
>
> Tegnap elkezdtem javítani az L2-nk teljesítményét. Néhány 
> próbálkozásom nem járt sikerrel, pl. a likely/unlikely semmit sem 
> javított, akárhová is tettem be; leírom, ami működött.
>
> 1. (3.7 GBps) Kezdetnek azt néztem meg, hogy mi történik akkor (a 
> performance branch-ből kiindulva, a test_dpdk2.sh-t futtatva), ha 
> lekapcsolom a handle_packet-et, és csak a dpdk_send_packet-tel küldöm 
> ki változatlanul a beérkező csomagokat. Ekkor a "gyári" l2fwd-hoz 
> hasonlóan telíteni kellett volna a 10 GBps-es csatornát, de csak 5.2 
> GBps-et mutatott a rendszer. Kiderült, hogy a burst használata 
> esszenciális; már nem emlékszem, miért kapcsoltam át r198-ban 
> egyenkénti csomagküldésre, de ha visszaírom olyanra a 
> dpdk_send_packet-et, mint az l2fwd_send_burst, akkor rögtön nő a 
> teljesítmény, handle_packet nélkül ki is maxolja az elérhető 10 gigát.
>
> 2. (5.2 GBps) A kódban ezenkívül egy dolog lassít jelentősen: a 
> dataplane.c-ben az lpm_lookup meghívása. Ha ezt kiiktatom, ismét 10 
> GBps-sel megyünk; ha meghagyom, a lookup kódjának a belsejében a 
> memcpy a főbűnös, ahogy azt mindenki korábban gyanította. Mivel a 
> konkrét esetben t->key_size == 14, ha a levél alján látható módon 
> külön kezelem ezt az esetet, és memcpy helyett simán átmásolom a 
> tartalmat, akkor hirtelen felszökik a sebesség. Arra már nem volt 
> időm, hogy a másolást máshogy is kipróbáljam, lehet, hogy bájtoknál 
> nagyobb egységekkel dolgozva még adódik valamekkora gyorsulás. 
> Illetve, ami még ebben a kódrészletben van, és lehet, hogy 
> gyorsítható, az maga az rte_lpm_lookup hívás, de azt nyilván kevésbé 
> szeretnénk újraimplementálni.
>
> Mivel ez egy speciális változtatás (a key_size értéke csak pont ebben 
> a példában fix 14), a másolást ennél általánosabban kell elintézni. 
> Lehet, hogy egy ügyes Duff's device megoldja, de az sem lehetetlen, 
> hogy valamilyen szinten hint-elni kell a fordítás során a programot: 
> vagy a P4 szintje alatt, vagy akár ez lehet egy javaslatunk a P4 
> kiterjesztésére.
>
> 3. (8.9 GBps) Ami még -- talán -- egy kicsit javít a futási 
> sebességen, az, ha a DPDK-t nem GCC-vel, hanem clang-gal fordítom. 
> Enélkül a sebesség első számjegye 8-as fölé nem ment, ezzel szinte 
> mindig 9-es volt, de ez csak akkora különbség, ami néha ingadozásként 
> is előjön. Még egy lehetőség, amit már nem értem rá próbálgatni: hátha 
> a DPDK-t EXTRA_CFLAGS='-O3' kapcsolóval fordítva gyorsabb lesz. A 
> saját kódunk GCC-vel és clang-gal egyformán teljesít, a jobb 
> hibaüzenetek miatt lehet, hogy érdemes áttérni clang-ra.
>
> 4. (9.1 GBps) Jelenleg itt tartunk. Mivel ez a jelenlegi konfiguráció 
> maximumától (10 GBps) nincsen túl messze, meg kell kérni a srácokat, 
> hogy adjanak hozzáférést a 40 GBps-es (vagy 100-as) kártyás gépekhez 
> is, mert még 10% gyorsulás, és már nem látjuk, mennyire jó a kód 
> teljesítménye. Peti, utána tudsz kérdezni?
>
> 5. A big/little endian konverzió koncepcionálisan persze fontos, hogy 
> hová kerül a kódban, de a teljesítményt nem valószínű, hogy érdemileg 
> befolyásolja: egyetlen bswap utasításra fordul le.
>
> Robi
>
> --------------------------------------------
>
> A gyorsuláshoz ezt toldottam be az lpm_lookup elágazásának első ágaként.
>
>
>     if(t->key_size == 14)
>     {
> //        uint8_t* key128 = calloc(16, sizeof(uint8_t));
> //        memcpy(key128, key, t->key_size);
>
> <------>uint8_t key128[16];
> key128[0] = key[0];
> key128[1] = key[1];
> key128[2] = key[2];
> key128[3] = key[3];
> key128[4] = key[4];
> key128[5] = key[5];
> key128[6] = key[6];
> key128[7] = key[7];
> key128[8] = key[8];
> key128[9] = key[9];
> key128[10] = key[10];
> key128[11] = key[11];
> key128[12] = key[12];
> key128[13] = key[13];
> key128[14] = 0;
> key128[15] = 0;
>
>
>         uint8_t result;
>         int ret = rte_lpm6_lookup(ext->rte_table, key128, &result);
>         return ret == 0 ? ext->content[result] : t->default_val;
>     }
>
> _______________________________________________
> P4 mailing list
> P4 at plc.inf.elte.hu
> https://plc.inf.elte.hu/mailman/listinfo/p4

-- 
Sándor Laki, PhD
Assistant professor
Department of Information Systems
Eötvös Loránd University
Pázmány Péter stny. 1/C
H-1117, Budapest, Hungary
Room 2.506
Web: http://lakis.web.elte.hu
Phone: +36 1 372 2869 / 8477
Cell: +36 70 374 2646