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

[Călin Cruceru]

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.

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).

>> [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
>>

Mersi,
Călin