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

[Matt Thomas <matt%3am-software.com@localhost>]

On Jun 21, 2014, at 9:48 PM, Darren Reed <darrenr%netbsd.org@localhost> wrote:

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

The problem is that the memory allocators won't honor it since they
will return a maximum alignment of ALIGNBYTES+1, where COHERENCY_UNIT
can be much higher than that.