[so2] [IXIA Challenge] Viteză mică de transfer la TX

[Adrian Stanciu]

2017-03-25 19:47 GMT+02:00 Călin Cruceru via so2 <so2 at cursuri.cs.pub.ro>:
> 2017-03-25 18:45 GMT+02:00 Alexandru Jercaianu via so2 <so2 at cursuri.cs.pub.ro>:
>> Salut,
>>
>> Nu este nevoie de sincronizare intre comenzi tx, deoarece existe un
>> xmit_lock care previne ndo_start_xmit sa se apeleze in paralel [1].
>>
>> [1] http://lxr.free-electrons.com/source/net/core/dev.c?v=2.6.32#L1952
>>
>
> Da, așa pare.  E derutant pentru că funcția ndo_xmit_frame, din câte
> înțeleg, obișnuia să se numească hard_xmit_frame.
>
>> 2017-03-25 18:36 GMT+02:00 Adrian Stanciu via so2 <so2 at cursuri.cs.pub.ro>:
>>> > De ce spui că cb_lock protejează CBL-ul de comenzi TX și non-TX și nu
>>> > ar proteja *și* comenzile TX de alte comenzi TX?  Întreb pentru că
>>> > exprimarea ta lasă de înțeles că dacă ar exista doar comenzi TX,
>>> > atunci nu ar fi nevoie de acel lock, ceea ce ar însemna că răspunsul
>>> > la întrebarea lui Iulian este "Nu", însă nu ai argumentat de ce.
>>> >
>>>
>>> Ar fi necesar și în cazul în care ar fi doar comenzi Tx, pentru că e
>>> folosit și în [2] și în [3], unde avem comenzi Tx. Dar la noi nu se
>>> aplică [3] pentru că nu folosim NAPI.
>>>
>>> Am spus doar că nu cred că ar trebui să sincronizeze două apeluri
>>> ndo_start_xmit, iar acel "nu cred" este din cauză că nu am avut timp
>>> să analizez în detaliu dacă kernelul poate ajunge să apeleze
>>> ndo_start_xmit în paralel. Dacă am timp, revin cu mai multe
>>> explicații.
>>>
>
> Cu toate astea, mă simt puțin nesigur în legătură cu modul în care ar
> trebui abordată implementarea unui device driver.  Mai precis, în ceea
> ce privește "filozofia" proiectării mecanismelor de sincronizare.
>
> Pe de-o parte, din câte înțeleg, este bine să previi problemele de
> sincronizare, și chiar dacă azi apelurile către funcțiile tale sunt
> linearizate, poate în viitor nu va mai fi așa și poate se merită să
> "plătești" un spin_lock care nu așteaptă niciodată, însă care va
> continua să funcționeze corect și când această garanție nu va mai
> exista.

Cred că în general se preferă eficiența față de folosirea mecanismelor
de sincronizare în mod preventiv. Chiar dacă spinlock-ul este gratuit
dpdv cpu dacă nu avem lock contention, acesta ocupă extra memorie (și
poate pe unele sisteme cu puțină memorie folosirea excesivă de locking
ar avea un impact semnificativ).

Dacă driver-ul este integrat în upstream, schimbările de API sau de
utilizare a callback-urilor vor fi anunțate de către autorul
modificărilor maintainer-ilor driver-ului și împreună vor aplica
modificările; deci nu ar trebui să aibă loc release-uri în care
driver-ul să nu funcționeze. Dacă driver-ul nu este integrat în
upstream trebuie ca la fiecare update de kernel să îți faci singur
portarea și validarea interfețelor.

> Pe de altă parte, nu știu cât de des au loc schimbări la acel nivel,
> deoarece are sens, într-un fel, ca această sincronizare să se
> realizeze în layerele superioare driverelor, deoarece acestea comunică
> direct cu hardware-ul la care accesul este inerent secvențial (în
> general).

Sunt de acord cu cele spuse de tine. Poate Tavi/Daniel, care au
experiență mai mare, dacă au timp, ne pot spune cum văd ei aceste
schimbări.


>>> [1]
>>> http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/e100.c?v=4.9#L61
>>> [2]
>>> http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/e100.c?v=4.9#L872
>>> [2]
>>> http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/e100.c?v=4.9#L1837
>>>
>


Adrian