Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On Jun 21, 2014, at 9:48 PM, Darren Reed <> wrote:

> On 22/06/2014 8:13 AM, Matt Thomas wrote:
>> On Jun 21, 2014, at 4:56 AM, Darren Reed <> 
>> wrote:
>>> On 21/06/2014 11:00 AM, Matt Thomas wrote:
>>>> On Jun 20, 2014, at 5:57 AM, Ryota Ozaki <> 
>>>> wrote:
>>>>> Hi,
>>>>> I've prepared a trial patch of MPSAFE networking.
>>>> 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.

Home | Main Index | Thread Index | Old Index