[P4] Fwd: Re: P4-es dolgok

Péter Vörös vpetya at mensa.hu
Mon May 28 13:23:10 CEST 2018


Sziasztok,

Az l2fwd jól működik!!!
Az l3fwd-nél a hit belseje viszont még nem jó.

control ingress {
       apply(macfwd) {
          hit {
               apply(ipv4_lpm); //EZEK A TÁBLÁK NEM KERÜLNEK ELŐ
               apply(nexthops); //EZEK A TÁBLÁK NEM KERÜLNEK ELŐ
          }
       }
}


[CORE 0 at 0] (  dataplane.c at 547) HANDLING PACKET (port 0, 64 bytes) : cc cc
cc cc 00 00 30 9c 23 5f 2e 4c 08 00 45 00 00 14 00 01 00 00 40 00 81 da c0
a8 00 65 32 00 06 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
[CORE 0 at 0] (     parser.c at 073) entering parser state start...
[CORE 0 at 0] (     parser.c at 037) entering parser state parse_ethernet...
[CORE 0 at 0] (     parser.c at 059) entering parser state parse_ipv4...
[CORE 0 at 0] (     parser.c at 080) entering parser state accept...
[CORE 0 at 0] (  dataplane.c at 534) Parsed packet
[CORE 0 at 0] (  dataplane.c at 537)  :::: Header ethernet (14 bytes): cc cc cc
cc 00 00 30 9c 23 5f 2e 4c 08 00
[CORE 0 at 0] (  dataplane.c at 537)  :::: Header     ipv4 (20 bytes): 45 00 00
14 00 01 00 00 40 00 81 da c0 a8 00 65 32 00 06 02
[CORE 0 at 0] (  dataplane.c at 387) entering control verifyChecksum...
[CORE 0 at 0] (  dataplane.c at 396) entering control ingress...
[CORE 0 at 0] (  dataplane.c at 078)   :::: EXECUTING TABLE macfwd
[CORE 0 at 0] (  dataplane.c at 089)     :: EXECUTING ACTION _nop_0... #### EZ
ITT MÉG JÓ
[CORE 0 at 0] (  dataplane.c at 144)   :::: EXECUTING TABLE tbl_act        ####
ITT KELLENE HOGY LEGYEN A HIT RÉSZ
[CORE 0 at 0] (  dataplane.c at 153)     :: EXECUTING ACTION act...
[CORE 0 at 0] (  dataplane.c at 429) entering control egress...
[CORE 0 at 0] (  dataplane.c at 438) entering control computeChecksum...
[CORE 0 at 0] (  dataplane.c at 447) entering control DeparserImpl...
[CORE 0 at 0] (  dataplane.c at 525)  :::: Reordering emit
[CORE 0 at 0] (  dataplane.c at 483)    :: Preparing 3 header instances for
storage...
[CORE 0 at 0] (  dataplane.c at 492)     : Storing  14 bytes (ethernet)  : cc cc
cc cc 00 00 30 9c 23 5f 2e 4c 08 00
[CORE 0 at 0] (  dataplane.c at 489)     : Skipping header   (     arp)  :
(invalid header)
[CORE 0 at 0] (  dataplane.c at 492)     : Storing  20 bytes (    ipv4)  : 45 00
00 14 00 01 00 00 40 00 81 da c0 a8 00 65 32 00 06 02
[CORE 0 at 0] (  dataplane.c at 497)    :: Stored   34 bytes             : cc cc
cc cc 00 00 30 9c 23 5f 2e 4c 08 00 45 00 00 14 00 01 00 00 40 00 81 da c0
a8 00 65 32 00 06 02
[CORE 0 at 0] (  dataplane.c at 514)    :: To emit 34 bytes (no resize)
[CORE 0 at 0] (  dataplane.c at 519)    :: Packet:  34 bytes from storage : cc cc
cc cc 00 00 30 9c 23 5f 2e 4c 08 00 45 00 00 14 00 01 00 00 40 00 81 da c0
a8 00 65 32 00 06 02
[CORE 0 at 0] (  main_loop.c at 323)   :::: EGRESSING
[CORE 0 at 0] (  main_loop.c at 331)     :: sending packet on port 0 (lcore 0)

Így lehet futtatni:
dpdk-switch:
P4_GCC_OPTS="-DP4DPDK_DEBUG" ./t4p4s.sh launch ctrl dpdk_l3fwd_controller
ctrcfg examples/l3fwd_table.txt examples/l3fwd-wo-chksm.p4
pktgen:
a run_pktgen-ben át kell írni a pcap foldert.
PCAP_FOLDER=/home/jenkins/t4p4s/examples/l3fwd_traffic.pcap

Üdv,
Peti

2018. május 27. 13:25 Brunner Márton írta, <brmarci at caesar.elte.hu>:

> Sziasztok!
>
> *A field_standard_metadata_t_checksum_error hibáról:*
>
> Ennek elvileg a $P4C/build/p4include/v1model.p4 fájlban szereplő struct
> standard_metadata_t definíció checksum_error mezőjéből automatikusan
> kellene generálódnia. Robi meg tudnád nézni, hogy nálad ez a fájl
> tartalmazza-e a field-et? (Kis furcsaság ehhez kapcsolódóan, hogy az @alias
> annotációval ellátott  mezők nem generálódnak nálunk le. Erre tud esetleg
> valaki valami magyarázatot?)
>
> *examples.cfg és dpdk_backend.mk <http://dpdk_backend.mk> hibák:*
>
> Két további apróbb hibát találtam. Az examples.cfg legutóbbi felcommitolt
> változatában az l2fwd-hoz kapcsoló sorban no-nic opció szerepelt (gondolom
> ez nem volt szándékos, úgyhogy ezt visszaírtam dpdk_default-os változatra).
> Valamint amikor a dpdk_backend.mk fájl végére írjuk az opcionális
> include-okat, akkor a régi makefájlt használjuk, így újra és újra
> bekerülnek az includok, amik fordítási hibához vezettek. Egyelőre azzal
> orvosoltam, hogy minden fordításkor kitöröljük a dpdk_backend.mk fájlt,
> de ennél biztosan lehetne szebben is.
>
> *Esetlegesen más branchen javított hibák:*
>
> A benti gépen (a p4 user home-ban) levő t4p4s-16 lokális változtatásai
> alapján úgy látom, hogy van egy pár hiba, ami úgy rémlik máshol már javítva
> lett, de itt szerintem csak a Sanyi javította őket ideiglenesen a múltkori
> teszteléskor. Az egyik egyik az volt, hogy a reset_headers meghívása azután
> történik, hogy a bejövő portot már beállítottuk és így az rögtön
> kinullázódik. A másik meg mintha valami port mérethez kapcsolódna (1
> bájtosként van commit-olva, 2 bájtosra van javítva). (Ezt csak azért írom
> le, mert ezeket érdemes lenne itt is javítani, illetve a további tesztelés
> folyamán figyelembe venni.)
>
> *Ezek után én sikeresen futtattam az l2fwd példát a benti gépen.*
>
> Arról fogalmam sincs, hogy pontosan mi történik, helyes-e a
> feldolgozás/kiküldés, mert ehhez kéne még egy tutoriál, hogy pontosan mit
> kéne figyelni az adatok közül. De a t4p4s-16 fordul, fut és nem száll el.
> Nálam van smac és dmac tábla is, látszódik, hogy mindkettőbe bekerülnek
> bejegyzések. Amikor elindítom a packet generation-t is, látszik, hogy
> jönnek a csomagok (azt már nem tudom eldönteni, hogy mit csinál velük
> pontosan). De nem kapok semmi segfault-ot vagy ilyesmit.
>
> Marci
>
> On 2018-05-25 12:50, Péter Vörös wrote:
>
> Szia,
>
> A field_standard_metadata_t_checksum_error hiba nálam előjött, de a
> komment megoldotta.
>
> Futtattam most az újjal is, de nemúgy tűnik hogy létrejön a dmac tábla,
> created table logja például egyáltalán nincs. Később pedig ezt írja ha fel
> akarjuk tölteni ([NO-CORE] Table setdefault: table name mismatch (dmac),
> expected one of (smac).) Full log ismét alul.
> A config tényleg nem volt rossz, csak a programot a ${DPDK_OPTS}-szal nem
> a ${DPDK_OPTS_TEXT}-tel akarta elindítani, ennyi volt csak a baj.
>
> A mostani config generálásnál viszont a sok kötőjel szerintem picit
> bekavar. Így ugyanis nem indul el a program.
> sudo -E ./build/l2fwd/build/l2fwd  - - - -c 0x3 -n 1 -- -p 0x3 --config
> "\"(0,0,0),(1,0,1)\"" - - - -c 0x3 -n 1 -- -p 0x3 --config
> "\"(0,0,0),(1,0,1)\""
>
> DPDK options  : v1model dpdk_default  l2fwd   2cores 2x1ports
> DPDK params   :  - - - -c 0x3 -n 1 -- -p 0x3 --config
> "\"(0,0,0),(1,0,1)\"" - - - -c 0x3 -n 1 -- -p 0x3 --config
> "\"(0,0,0),(1,0,1)\""
>
>
> Kézzel javítva erre: sudo -E ./build/l2fwd/build/l2fwd  -c 0x3 -n 1 -- -p
> 0x3 --config "\"(0,0,0),(1,0,1)\"" -- -p 0x3 --config "\"(0,0,0),(1,0,1)\""
> már fut.
>
> Üdv,
> Peti
>
> [CORE 0 at 0] (   dpdk_lib.c at 581) Initializing stateful memories...
> [CORE 0 at 0] (   dpdk_lib.c at 481) Initializing tables on socket 0...
> [CORE 0 at 0] (   dpdk_lib.c at 485) Creating instances for table smac on
> socket 0 (2 copies)
> [CORE 0 at 0] (   dpdk_lib.c at 474) Created table smac on socket 0.
> [CORE 0 at 0] (   dpdk_lib.c at 474) Created table smac on socket 0.
> [CORE 0 at 0] (   dpdk_lib.c at 510) Initializing counters on socket 0...
> [CORE 0 at 0] (   dpdk_lib.c at 533) Initializing registers...
> [CORE 0 at 0] (   dpdk_lib.c at 603) Configuring lcore structs...
> [CORE 0 at 0] (controlplane.c at 096) Creating control plane connection...
> [CTRL]  :::: SET_DEFAULT_ACTION
> [CTRL]    :: rval=0
> [NO-CORE] MSG from controller 103 smac
> [NO-CORE] Action name: mac_learn
> [NO-CORE] Message from the control plane arrived.
> [NO-CORE] Set default action for smac with action mac_learn
> [NO-CORE] Default value set for table smac (on socket 0).
> [NO-CORE] Default value set for table smac (on socket 0).
> [CTRL] Handle msg: 0
> [CTRL]  :::: SET_DEFAULT_ACTION
> [CTRL]    :: rval=0
> [NO-CORE] MSG from controller 103 dmac
> [NO-CORE] Table setdefault: table name mismatch (dmac), expected one of
> (smac).
> [CTRL] Handle msg: 0
> [CTRL]  :::: ADD_TABLE_ENTRY
> [CTRL]    :: rval=0
> [NO-CORE] MSG from controller 104 dmac
> [NO-CORE] Table add entry: table name mismatch (dmac), expected one of
> (smac).
> [CTRL] Handle msg: 0
> [CTRL]  :::: ADD_TABLE_ENTRY
> [CTRL]    :: rval=0
> [NO-CORE] MSG from controller 104 smac
> [NO-CORE] Reply from the control plane arrived.
> [NO-CORE] Adding new entry to smac with action _nop_0
> [NO-CORE] EXACT: Added key: aa:cc:dd:cc:00:01
> 0 (0x7fd484000900)
> [NO-CORE] EXACT: Added key: aa:cc:dd:cc:00:01
> 0 (0x7fd484000920)
> [CTRL] Handle msg: 0
> [CTRL]  :::: ADD_TABLE_ENTRY
> [CTRL]    :: rval=0
> [NO-CORE] MSG from controller 104 dmac
> [NO-CORE] Table add entry: table name mismatch (dmac), expected one of
> (smac).
>
>
> 2018. május 25. 12:31 Kitlei Róbert írta, <kitlei at elte.hu>:
>
>>
>> Sziasztok,
>>
>>
>> [NO-CORE] Table add entry: table name mismatch (dmac).
>> Nincs dmac nevű táblánk?
>>
>>
>> Futtasd a legújabb committal, kiírja majd, hogy szerinte milyen táblák
>> érhetőek el.
>>
>> 1. dolog amibe belefutottam: a t4p4s nem jól oldja fel az
>> examples.cfg-ben a dpdk_paramétereket.
>>
>>
>> Épp most frissítettem a konfig szerkezetét és felolvasását.
>>
>> Futtatásnál látszik is.
>>   - DPDK options  : 2cores,2x1ports
>>   - DPDK params   :  -c 0x3 -n 1 -- -p 0x3 --config "\"(0,0,0),(1,0,1)\""
>>
>>
>> A t4p4s.sh itt jó adatokat vesz fel a dpdk_parameters.cfg-ből, ezek a
>> paraméterek felelnek meg a 2cores,2x1ports opcióknak. (Az új változatban
>> szóközzel lesznek elválasztva.) Nem ezeknek kellene jönniük?
>>
>> A kód azért nem megy, mert gondolom a Robi nem v1model-es kódot
>>> fordított, viszont a v1model-es externeket tartalmazó fájl is be volt
>>> include-olva. Mivel ott hivatkozunk olyan elemre, ami csak v1model-es p4
>>> fájl esetén generálódik le, így ez hibához vezetett.
>>>
>>
>> Megnéztem, mindegyik példánk v1model-es. Nálam mégsem generálódik a
>> field_standard_metadata_t_checksum_error, amit annyira hiányol a
>> rendszer, nálad igen?
>>
>> Viszont az emiatt bevezetett int abban az esetben okoz hibát, ha
>>> v1model-es példát fordítanánk. Én a megoldást abban látom (és ez már
>>> többször is felmerült), hogy nem kéne minden extern deklarációkat
>>> tartalmazó fájlt include-olni, csak az aktuálisan használt architektúrának
>>> megfelelőt. (Workaroundként elegendő a src/hardware_dep/dpdk/data_plane/dpdk_v1model_extern.c
>>> fájlban kicommentezni a checksum_error-os int-et.)
>>>
>>
>> Így van, a hack-et nem is akartam feltölteni, de saját akarata van. :)
>> Mostanra lett elég okos a konfigurációk kiválasztása.
>>
>> ... A másik felében ezek között jön egy "PANIC in rte_free():", majd
>>> "Fatal error: Invalid memory", ami aztán valami szép hibaüzenettel elszáll:
>>>
>>
>> Ilyen néha nálam is jelentkezik, még nem tudom, miért. Az érdekes, hogy
>> egy setdefault kellős közepén történik...
>>
>> Robi
>>
>>
>> _______________________________________________
>> P4 mailing list
>> P4 at plc.inf.elte.hu
>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>
>>
>
>
> _______________________________________________
> P4 mailing listP4 at plc.inf.elte.huhttps://plc.inf.elte.hu/mailman/listinfo/p4
>
>
>
> _______________________________________________
> P4 mailing list
> P4 at plc.inf.elte.hu
> https://plc.inf.elte.hu/mailman/listinfo/p4
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://plc.inf.elte.hu/pipermail/p4/attachments/20180528/3fdce83f/attachment-0001.html>


More information about the P4 mailing list