[P4] Meres
Péter Vörös
vopraai at caesar.elte.hu
Tue Dec 15 11:40:42 CET 2015
Sziasztok,
Feltettem Dani patch-ét, de sajnos ettől nem lettünk gyorsabbak.
Mátéval beszéltük hogy nézzem meg az l2fwd esetében mit mutat a perf:
45.99% l2fwd [.] _recv_raw_pkts_vec
37.23% l2fwd [.] l2fwd_main_loop
12.52% l2fwd [.] ixgbe_xmit_pkts_vec
1.76% l2fwd [.] l2fwd_send_burst
1.35% libc-2.19.so [.] __memcpy_sse2_unaligned
1.00% l2fwd [.] ixgbe_recv_pkts_vec
Nalunk ez kb igy nez ki:
43.94% example_dpdk1 [.] apply_table_smac
14.03% example_dpdk1 [.] packet_received
9.77% example_dpdk1 [.] rx_recv_pkts
6.36% example_dpdk1 [.] rte_hash_lookup
5.77% example_dpdk1 [.] ixgbe_xmit_pkts_vec
5.23% example_dpdk1 [.] extract_intvalue
Mind az apply table-ben, mind a packet_recieved-ben a field_desc-nel
van a problema meg mindig.
Nem nagyon értek a macrókhoz, de a field_desc az nem hoz létre egy új
struktúrát, nem azért lassú ez az egész?
--------------packet_recieved---------------
│ int inport = extract_intvalue(pd,
field_desc(field_instance_standard_metadata_ingress_port));
│ mov 0x80(%rsp),%rax
16.45 │ movl $0x9,0x88(%rsp)
│ movl $0x2,0x8c(%rsp)
│ movl $0x0,0x90(%rsp)
│ mov %rax,(%rsp)
1.06 │ mov 0x88(%rsp),%rax
15.96 │ movl $0x0,0x94(%rsp)
│ movl $0x1ff,0x98(%rsp)
│ movl $0x1ff,0x18(%rsp)
│ mov %rax,0x8(%rsp)
1.17 │ mov 0x90(%rsp),%rax
14.26 │ mov %rax,0x10(%rsp)
0.88 │ → callq extract_intvalue
--------------apply table---------------
│ void table_smac_key(packet_descriptor_t* pd, uint8_t*
key) {// sugar at 24
│ memcpy(key, extract_bytebuf(pd,
field_desc(field_instance_ethernet_srcAddr)), 6);// sugar at 32
0.30 │ movl $0x1,0x20(%rsp)
0.03 │ movl $0x0,0x24(%rsp)
0.07 │ mov 0x20(%rsp),%rax
75.43 │ movl $0x30,0x28(%rsp)
│ movl $0x6,0x2c(%rsp)
│ movl $0x0,0x30(%rsp)
│ mov %rax,(%rsp)
0.34 │ mov 0x28(%rsp),%rax
5.12 │ movl $0x6,0x34(%rsp)
│ movl $0x0,0x38(%rsp)
│ movl $0x0,0x18(%rsp)
│ mov %rax,0x8(%rsp)
0.38 │ mov 0x30(%rsp),%rax
4.62 │ mov %rax,0x10(%rsp)
0.33 │ → callq extract_bytebuf
Dániel Horpácsi <daniel-h at elte.hu> írta (2015. december 14. 18:52):
> Szia!
>
> Jó látni, milyen intenzitással lendültél a munkába :) Egy pillanattal
> ezelőtt feltöltöttem egy olyan módosítást, ami a modify_field primitív
> akciót már makróhívásokra fordítja, tehát nincs többé a függvényhívás
> költsége és remélhetőleg a field_desc törzse sem marad a tárgykódban.
>
> Üdv,
> Dani
>
>
> On 2015-12-14 14:37, Péter Vörös wrote:
>>
>> Kimertem, a DPDK l2fwd 10Gb/s et tudja.
>> Nem a p4 mar nem broadcastol.
>>
>>
>> Egy picit atalakitottam a modify_field_to_const reszt, most mar ott
>> sincs performance vesztes ezzel 2.5Gb/s korul vagyunk
>>
>> Tovabb nyomoztam mi lassit meg minket:
>> 40.62% example_dpdk1 [.] apply_table_smac
>> 13.13% example_dpdk1 [.] packet_received
>>
>> Az apply_table_smac-ben:
>> │ void apply_table_smac(packet_descriptor_t* pd,
>> lookup_table_t** tables);// sugar at 15
>> │ void apply_table_dmac(packet_descriptor_t* pd,
>> lookup_table_t** tables);// sugar at 15
>> │
>> │ void table_smac_key(packet_descriptor_t* pd, uint8_t*
>> key) {// sugar at 24
>> │ memcpy(key, extract_bytebuf(pd,
>> field_desc(field_instance_ethernet_srcAddr)), 6);// sugar at 32
>> 0.31 │ movl $0x1,0x20(%rsp)
>> 0.04 │ movl $0x0,0x24(%rsp)
>> 0.06 │ mov 0x20(%rsp),%rax
>> ****
>> **** 74.77 │ movl $0x30,0x28(%rsp)*****
>> ****
>> 0.00 │ movl $0x6,0x2c(%rsp)
>> │ movl $0x0,0x30(%rsp)
>> │ mov %rax,(%rsp)
>> 0.35 │ mov 0x28(%rsp),%rax
>> 4.99 │ movl $0x6,0x34(%rsp)
>> │ movl $0x0,0x38(%rsp)
>> │ movl $0x0,0x18(%rsp)
>> │ mov %rax,0x8(%rsp)
>> 0.34 │ mov 0x30(%rsp),%rax
>> 4.72 │ mov %rax,0x10(%rsp)
>> 0.30 │ → callq extract_bytebuf
>> │ void apply_table_smac(packet_descriptor_t* pd,
>> lookup_table_t** tables)// sugar at 42
>>
>> Szerintem a field_desc makro a ludas. A packet_recieved fuggvenyben is
>> annak a kornyeken lathato a komoly lassulas.
>>
>> Peti
>>
>> Sandor Laki <lakis at elte.hu> írta (2015. december 14. 15:29):
>>>
>>> Mérd már ki a dpdk l2fwd esetén is performance-t.
>>>
>>> Más: a p4 esetén még mindig broadcastol? Ha igen, akkor az is lassít...
>>>
>>> Üdv.
>>> Sanyi
>>>
>>>
>>> 2015.12.14. 15:11 keltezéssel, Péter Vörös írta:
>>>>
>>>> Most futtatom, az a 10Gb/s kartyat ami ebben a gepben van totalban
>>>> kihasznalja.
>>>>
>>>> Sandor Laki <lakis at elte.hu> írta (2015. december 14. 15:02):
>>>>>
>>>>> Hi,
>>>>>
>>>>> Nyomnál egy dpdk l2fwd-ot is? Csak, hogy lássuk azt is...
>>>>>
>>>>> Üdv.
>>>>> Sanyi
>>>>>
>>>>>
>>>>> 2015.12.14. 14:46 keltezéssel, Péter Vörös írta:
>>>>>>
>>>>>> A perf vizsgalat eredmenye:
>>>>>>
>>>>>> 33.39% example_dpdk1 [.] crc32
>>>>>> 28.76% example_dpdk1 [.] packet_received
>>>>>> 7.71% example_dpdk1 [.] apply_table_smac
>>>>>> 5.61% example_dpdk1 [.] rx_recv_pkts
>>>>>>
>>>>>> Volt annak valami jelentossege, hogy a CRC szamolats sajat magunk
>>>>>> implementaltuk?
>>>>>> Lecsereltem a sajat implementacionkat a rte_hash_crc.h-ben
>>>>>> implementaltra (rte_hash_crc), ezzel javult jelentosen a dolog
>>>>>> 2.2Gb-nel jarunk.
>>>>>>
>>>>>> Peti
>>>>>>
>>>>>> Péter Vörös <vopraai at caesar.elte.hu> írta (2015. december 14. 14:34):
>>>>>>>
>>>>>>> A calloc-ot kivezettem a while(1)-bol, ezzel ~1.5Gb/s re nott a
>>>>>>> sebesseg, ennel meg mindig jobbnak kellene lennunk.
>>>>>>>
>>>>>>> Péter Vörös <vpetya at mensa.hu> írta (2015. december 14. 14:23):
>>>>>>>>
>>>>>>>> Sziasztok!
>>>>>>>>
>>>>>>>> Na sikerult beizzitani a merest, kiszedtem a printeket, O3mal
>>>>>>>> forditok, meg egy kicsit buzeraltam a kodot ezzel feltornaztam a
>>>>>>>> teljesitmenyunket 1.3Gb/s-re.
>>>>>>>>
>>>>>>>> Amugy bekapcsoltam az RSS-t, de egyelore nem vezet javulashoz, mert
>>>>>>>> ez
>>>>>>>> a hardware nem, illetve nem ugy tamogatja az RSS-t. Az
>>>>>>>> Ericssonosokkal
>>>>>>>> egyeztettem mar egy csomot, azt mondtak 1. korben nem is olyan rossz
>>>>>>>> ez a szam, foleg ugy hogy meg calloc-olunk. De RSS nelkul el lehetne
>>>>>>>> erni a 19Gb/s-t szoval ahogy mondtak: "van meg rejtett eroforras
>>>>>>>> amit
>>>>>>>> ki kellene hasznalni".
>>>>>>>> Szoval azt mondtak, hogy RSS nelkul probaljuk novelni ezt a szamot.
>>>>>>>>
>>>>>>>> Jelenleg epp azt nezem hogy miert nem tobbet, a hibe valszeg, hogy
>>>>>>>> meg
>>>>>>>> mindig van calloc fast path-on:
>>>>>>>> init_metadata(packet_descriptor_t* packet_desc, uint32_t inport)
>>>>>>>> {
>>>>>>>> packet_desc->headers[header_instance_standard_metadata] =
>>>>>>>> (header_descriptor_t) {
>>>>>>>> .type = header_instance_standard_metadata,
>>>>>>>> .length =
>>>>>>>> header_instance_byte_width[header_instance_standard_metadata],
>>>>>>>> ****
>>>>>>>> **** .pointer =
>>>>>>>>
>>>>>>>> calloc(header_instance_byte_width[header_instance_standard_metadata],
>>>>>>>> sizeof(uint8_t)) ****
>>>>>>>> ****
>>>>>>>> };
>>>>>>>> modify_field_to_const(packet_desc,
>>>>>>>> field_desc(field_instance_standard_metadata_ingress_port),
>>>>>>>> (uint8_t*)&inport, 2);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Ezt minden csomagnal megcsinaljuk es valszeg nem tul egeszseges a
>>>>>>>> teljesitmeny szempontjabol.
>>>>>>>>
>>>>>>>> Peti
>>>>>>>>
>>>>>>>> Tejfel Máté <matej at caesar.elte.hu> írta (2015. december 14. 9:54):
>>>>>>>>>
>>>>>>>>> Sziasztok!
>>>>>>>>>
>>>>>>>>> Most látom (most a logot is meg tudtam nézni :) ), hogy
>>>>>>>>> teljesen
>>>>>>>>> félreértettem Sanyi első levelét. Azt hittem már a controllertől se
>>>>>>>>> jön
>>>>>>>>> meg
>>>>>>>>> a válasz, ezért broadcastol. Viszont ezek szerint funkcionálisan
>>>>>>>>> igazából
>>>>>>>>> jól működik. Így akkor tényleg nincs sok jelentősége a
>>>>>>>>> generate_digest-nek...
>>>>>>>>>
>>>>>>>>> M.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2015-12-13 22:05 keltezéssel, Sandor Laki írta:
>>>>>>>>>>
>>>>>>>>>> Várhatóan a generate_digest nem jelent sokat, mivel az csak az
>>>>>>>>>> első
>>>>>>>>>> csomagnál hívódik meg.
>>>>>>>>>>
>>>>>>>>>> Üdv.
>>>>>>>>>> Sanyi
>>>>>>>>>>
>>>>>>>>>> 2015.12.13. 14:42 keltezéssel, Tejfel Máté írta:
>>>>>>>>>>>
>>>>>>>>>>> Sziasztok!
>>>>>>>>>>>
>>>>>>>>>>> Peti, amit még esetleg kipróbálhatnál, hogy a pénteki
>>>>>>>>>>> konfignál,
>>>>>>>>>>> ha már
>>>>>>>>>>> úgyis mindig broadcast-ol,
>>>>>>>>>>> a) mi van, ha az actions.c-ben, az action_code_mac_learn
>>>>>>>>>>> végén
>>>>>>>>>>> nem
>>>>>>>>>>> csak a sleep(1)-et kommentezed ki, hanem a generate_digest-et is,
>>>>>>>>>>> illetve
>>>>>>>>>>> b) mi van, ha a teljes action_code_mac_learn-t
>>>>>>>>>>> kikommentezed
>>>>>>>>>>> (persze mindkettőnél az összes print eltüntetése mellett)
>>>>>>>>>>> Ez is tanulságos eredményt adhat...
>>>>>>>>>>>
>>>>>>>>>>> PS: a gcc-t ugye -O3 flag-el futtatod, had optimalizáljon,
>>>>>>>>>>> amit
>>>>>>>>>>> tud?
>>>>>>>>>>>
>>>>>>>>>>> M.
>>>>>>>>>>>
>>>>>>>>>>> 2015-12-12 23:16 keltezéssel, Péter Vörös írta:
>>>>>>>>>>>>
>>>>>>>>>>>> Igen köszi a tippet, erre már gondoltam én is, de a
>>>>>>>>>>>> broadcastolás
>>>>>>>>>>>> miatt egyáltalán nem lehetett mérni a teljesítményt szóval
>>>>>>>>>>>> először
>>>>>>>>>>>> azt
>>>>>>>>>>>> akartam áthidalni.
>>>>>>>>>>>> Ha már megérkeznek jól a csomagok, akkor kikommentezem a
>>>>>>>>>>>> printeket
>>>>>>>>>>>> a
>>>>>>>>>>>> további mérésekhez.
>>>>>>>>>>>>
>>>>>>>>>>>> Peti
>>>>>>>>>>>>
>>>>>>>>>>>> Sandor Laki <lakis at elte.hu> írta (2015. december 12. 23:11):
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ami még megfoghatja, a logolás, azaz a sok println...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Üdv.
>>>>>>>>>>>>> Sanyi
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2015.12.12. 22:14 keltezéssel, Péter Vörös írta:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Szia,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Oké, hétfőn kipróbálom.
>>>>>>>>>>>>>> A l2fwd-t nem néztem meg mert a srácok azt mondták, hogy
>>>>>>>>>>>>>> felesleges,
>>>>>>>>>>>>>> látták már ezerszer, az tud 25Gb/s-t. De csak hogy a configról
>>>>>>>>>>>>>> megbizonyosodjak azt is lefuttatom majd.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Peti
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sandor Laki <lakis at elte.hu> írta (2015. december 12. 21:46):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Szia,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A backward maclearning miatt, mivel nem jön válasz az áttolt
>>>>>>>>>>>>>>> csomagokra,
>>>>>>>>>>>>>>> így
>>>>>>>>>>>>>>> broadcastolni fog végig, ami elég műveletigényes, és ehhez
>>>>>>>>>>>>>>> lehet,
>>>>>>>>>>>>>>> hogy
>>>>>>>>>>>>>>> mempool is kicsi, ami most be van állítva. Persze mivel 2
>>>>>>>>>>>>>>> portunk
>>>>>>>>>>>>>>> van,
>>>>>>>>>>>>>>> elvben a broadcastot is lehetne ügyesebben csinálni. Amit ki
>>>>>>>>>>>>>>> tudsz
>>>>>>>>>>>>>>> próbálni:
>>>>>>>>>>>>>>> 1. az elején a port1-en is beküldesz egy csomagot a
>>>>>>>>>>>>>>> célállomás
>>>>>>>>>>>>>>> mac
>>>>>>>>>>>>>>> címével,
>>>>>>>>>>>>>>> azaz a src mac ez legyen: 00:25:90:91:1B:2B. Eztán pedig
>>>>>>>>>>>>>>> indíthatod a
>>>>>>>>>>>>>>> korábbi kísérletet.
>>>>>>>>>>>>>>> 2. a dpdk l2fwd példája mit tud? Azt kellene baseline-nak
>>>>>>>>>>>>>>> tekinteni.
>>>>>>>>>>>>>>> Ha
>>>>>>>>>>>>>>> az
>>>>>>>>>>>>>>> is lassú, akkor még van konfigurációs probléma is...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Üdv.
>>>>>>>>>>>>>>> Sanyi
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2015.12.11. 16:09 keltezéssel, Péter Vörös írta:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sziasztok!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mar par oraja jatszok a teszt beinditasaval, valami tortenik.
>>>>>>>>>>>>>>> Latszik
>>>>>>>>>>>>>>> hogy kapunk egy rakalp csomagot, az viszont nekem nem tiszta,
>>>>>>>>>>>>>>> hogy mi
>>>>>>>>>>>>>>> az a pont ahol meghal.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A baj az, hogy a leglassabb rate beallitasra is mar ez
>>>>>>>>>>>>>>> tortenik.
>>>>>>>>>>>>>>> (ami
>>>>>>>>>>>>>>> kb 100Mb/s)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Megtudtam kozben a titkos szamot is kb 25Gb/s-t kellene
>>>>>>>>>>>>>>> tudnunk.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lehet, hogy valami nincs meg tokeletesen konfigolva, mert nem
>>>>>>>>>>>>>>> ertem
>>>>>>>>>>>>>>> miert akar mindig broadcastolni. Hetfon folytatom.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Peti
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> P4 mailing list
>>>>>>>>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> P4 mailing list
>>>>>>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> P4 mailing list
>>>>>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> P4 mailing list
>>>>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> P4 mailing list
>>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> P4 mailing list
>>>>> P4 at plc.inf.elte.hu
>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>>> P4 mailing list
>>> P4 at plc.inf.elte.hu
>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>
>> _______________________________________________
>> P4 mailing list
>> P4 at plc.inf.elte.hu
>> https://plc.inf.elte.hu/mailman/listinfo/p4
>
>
> _______________________________________________
> P4 mailing list
> P4 at plc.inf.elte.hu
> https://plc.inf.elte.hu/mailman/listinfo/p4
More information about the P4
mailing list