Re: RFC: mpsafe bridge and NIC drivers (vioif and wm)

[Darren Reed <darrenr%netbsd.org@localhost>]

On 22/06/2014 8:13 AM, Matt Thomas wrote:
> On Jun 21, 2014, at 4:56 AM, Darren Reed <darrenr%netbsd.org@localhost> wrote:
>> On 21/06/2014 11:00 AM, Matt Thomas wrote:
>>> On Jun 20, 2014, at 5:57 AM, Ryota Ozaki <ozaki-r%iij.ad.jp@localhost> 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've prepared a trial patch of MPSAFE networking.
>>>>
>>>> http://www.netbsd.org/~ozaki-r/mpsafe-wm.diff
>>>>
>>> The kmutex_t in ifqueue, etc. should be pointers and not in the structure 
>>> themselves.
>>> That can simply the macros to test for a NULL pointer for the locks in the 
>>> non-WM case.
>>>
>>> Consider using mutex_obj_alloc to get mutexes instead of the embedding them 
>>> in the
>>> structures.
>>
>> This coding pattern goes against what is done almost everywhere else.
>>
>> What's the rationale behind it?
> 
> That's not true.  uvm_object's, sockets, etc. all use external kmutex's.
> In this isntance It allows for the ifqueue to use device kmutex is
> there is one. Also, mutexes should be cacheline aligned and that is
> difficult to do in a structure where mutex_obj_alloc does that 
> autmoatuiccally.

Ah, I didn't know that this type of approach was used elsewhere in
NetBSD. Are there any compiler hints that can be embedded in structs
that will result in padding and correct alignment? My solution has
been to always put the lock(s) at the front of a structure.
Can  __attribute__((aligned(X)) be used appropriately here or is it
likely to be ignored in the middle of a structure?

Darren