Subject: Re: [PATCH RFC 1/2] net: dsa: integrate with SWITCHDEV for HW bridging

From: Andrey Volkov <[email-masked]>
Date: Wed, 04 Mar 2015 11:07:18 +0100

Gunter,

On 02/03/2015 18:16, Guenter Roeck wrote:
> On 03/02/2015 07:27 AM, Andrey Volkov wrote:
>> On 02/03/2015 15:49, Guenter Roeck wrote:
>>> On 03/02/2015 06:38 AM, Andrey Volkov wrote:
>>>>
>>>> On 28/02/2015 08:53, Guenter Roeck wrote:
>>>>> On 02/27/2015 09:09 AM, Andrey Volkov wrote:
>>>>>> Gunter,
>>>>>>
>>>>>> Sorry with response delay, I very was busy yesterday
>>>>>>
>>>>>> Le 25/02/2015 15:25, Guenter Roeck a écrit :
>>>>>>> Andrey,
>>>>>>
>>>>>> ------- snip -------
>>>>>>
>>>>>>>>>
>>>>>>>> I simply modify port's fid to the new one in the leave routine and set to common bridge FID in enter
>>>>>>>> (I'm using Marvell's chips). So the port's database will cleaned up automatically for the leave and will
>>>>>>>> contain something useful at the enter time. Also I've look through yours patches and I haven't
>>>>>>>
>>>>>>> Does removing a port from a fid clean up the entries associated with it
>>>>>>> in the database ?
>>>>>>
>>>>>> I've checked what happened when port changed its FID: switch logic block traffic to it
>>>>>> immediately, as far as I can see, meanwhile record still exists in the bridge database,
>>>>>> it was checked on 88e6185, 88e6097 and 88e6352 chips. And yet another 5c: changing of group membership is
>>>>>> not atomic operation in the Marvell's chips known for me, so the port must be in the disabled state when it
>>>>>> will happened.
>>>>>>
>>>>> Hmm - interesting. I assume you mean updating port registers 5 and 6 ?
>>>> Yes sure, it's reason why we must disable the port before changing the FID.
>>>>
>>> Yes, I think we'll need to do that once we use the bits in register 5.
>>>
>>>>>
>>>>> Different question: For 6185, did you write a new driver or extend an existing one ?
>>>>> I found that it is quite similar to 6131, and that adding support for it to the 6131
>>>>> driver should be straightforward.
>>>> Yes again :), and 88E6097 have same core as 6123_61_65. Difference in both cases only in the number
>>>> of supported ports, and it was main reason why hardcoded port's number was unacceptable for me, difference is
>>>> large enough: for ex. 88e6123 have only 3 ports, but 88E6097 - 11.
>>>>
>>>
>>> I have a patch set to change the number of ports to a variable in the 6131 driver.
>>> Want me to submit it now ? Though I guess you must have pretty much the same,
>>> so we can also use your approach. Let me know.
>>
>> I think that better to start from my patches: they are more generic and have support of sysfs
>> (should be useful for "MII over ethernet"). Also IMO it will be better if we continue exchange/prereview
> 
> Sure, no problem. Only concern I have is that your patches don't seem to be available
> in public, or maybe I missed the reference to it.
No I didn't publish them yet, sorry, I plan to submit them at the end of next week,
as I've wrote before, but if this date is late for you, then yes, 
I think that we could begin from your patches.

> 
>> our patches in more narrow mail list, since I do not want to pollute netdev by useless discussions about drafts.
>> Objections/suggestions?
>>
> Sure, no problem, though personally I have no issues with the discussions
> or with submitting draft patches, and I did not have the impression that
> they are useless.
Ok, I've just mean to simplify discussion, especially that David told about his 
fresh hardware switches related project, so ok this mail list then then this mail list.

> 
> My patches are all in my repository at kernel.org; it is fine with me to keep
> them (only) there if submitting drafts to netdev is considered pollution.
Nice, I'll keep this thing in mind.

Thank you
Andrey