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

[Adrian Stanciu]

2017-03-25 18:14 GMT+02:00 Călin Cruceru <crucerucalincristian at gmail.com>:
> 2017-03-25 17:37 GMT+02:00 Adrian Stanciu via so2 <so2 at cursuri.cs.pub.ro>:
>> 2017-03-25 10:50 GMT+02:00 Iulian Matesica <iulian.matesica at gmail.com>:
>>> Pe 25 martie 2017, 06:50, Adrian Stanciu <adrian.stanciu.pub at gmail.com> a scris:
>>>> Dimensiunea ring-urilor și a elementelor componente. Să vezi pentru ce
>>>> dimensiune ai cea mai mare viteză, să vezi de ce alocarea mai multor resurse
>>>> nu ajută (locking-ul are un impact mai mare?).
>>>
>>> Funcția nod_start_xmit() poate fi apelata concurent de către
>>> subsistemul de networking, nu?
>>
>> Nu cred că kernelul va apela ndo_start_xmit() pe același device în paralel.
>> În sursa oficială sunt două lock-uri [1], unul pentru serializarea
>> comenzilor și unul pentru CBL-ul partajat de comenzi Tx și non-Tx.
>>
>
> 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.

[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