On 25.6.2021. 10:02, Alexandr Nedvedicky wrote:
> Hello David,
>
>
>>
>> during the drive to work it occurred to me that we should basically have
>> the same logic around whether we should insert or replace or do nothing
>> in both the smr and mutex critical sections.
>>
>> it at least makes the
Hello David,
>
> during the drive to work it occurred to me that we should basically have
> the same logic around whether we should insert or replace or do nothing
> in both the smr and mutex critical sections.
>
> it at least makes the code easier to understand. i think?
yes, the new diff
On Thu, Jun 24, 2021 at 09:31:20AM +0200, Alexandr Nedvedicky wrote:
> Hello David,
>
>
> >
> > i think we can get away with not refcounting eb_entry structures at all.
> > either they're in the etherbridge map/table or they're not, and the
> > thing that takes them out of the map while holding
Hello David,
>
> i think we can get away with not refcounting eb_entry structures at all.
> either they're in the etherbridge map/table or they're not, and the
> thing that takes them out of the map while holding the eb_lock mutex
> becomes responsible for their cleanup.
>
> i feel like most of
On Sat, Jun 19, 2021 at 12:32:04AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> skip reading if you are not interested in L2 switching combined
> with bluhm's diff [1], which enables parallel forwarding.
>
> Hrvoje gave it a try and soon discovered some panics. Diff below
> fixes a panic indica
Hello,
skip reading if you are not interested in L2 switching combined
with bluhm's diff [1], which enables parallel forwarding.
Hrvoje gave it a try and soon discovered some panics. Diff below
fixes a panic indicated by stack as follows:
login: panic: kernel diagnostic assertion "smr->smr_f
