net/dsa

net/dsa

[Karl Beldan]

Hi,

I found the dsa code very handy to help manage a switch.
Yet I was surprised I had to tweak the code to simply use the phy layer
state machine.
And I don't see much activity in the code nor any discussion, e.g no
follow up to http://patchwork.ozlabs.org/patch/16578.

So I was wondering if there was anybody playing with this code, or
having ideas about features to add (vlan/stp callbacks) ?



Karl

Re: net/dsa

[Lennert Buytenhek]

On Mon, Jul 12, 2010 at 10:59:29PM +0200, Karl Beldan wrote:

> Hi,

Hi Karl,

Sorry, I didn't see your mail initially -- please CC me in the future.


> I found the dsa code very handy to help manage a switch.

Ah.  What particular part are you using?


> Yet I was surprised I had to tweak the code to simply use the phy
> layer state machine.

You mean that net/dsa uses phy_attach() but not phy_start_machine() ?
Have you seen problems arising from this?


> And I don't see much activity in the code nor any discussion, e.g no
> follow up to http://patchwork.ozlabs.org/patch/16578.
> 
> So I was wondering if there was anybody playing with this code, or
> having ideas about features to add (vlan/stp callbacks) ?

As far as I know, the code currently in the kernel works well for what
it intends to do (which is to just expose the switch ports), and I'm
not aware of any bugs in it.

That said, you're right in that there are several more features that
the hardware supports that the software could be extended to handle.

For one, I don't have access to any Marvell switch chip hardware
anymore, so that limits my ability to play with this.  Also, the
relevant documentation is under a rather restrictive license, so the
only way I can see net/dsa support for Marvell parts improving is if
there's pressure from a large enough customer to make this happen.

If this is about non-Marvell parts, I'd welcome adding support for
those into net/dsa.  For one, I would really like to see Broadcom
switch chip support added -- the documentation for those chips is
under similarly restrictive licensing, though.


thanks,
Lennert

Re: net/dsa

[Karl Beldan]

On Tue, Jul 20, 2010 at 3:59 PM, Lennert Buytenhek
<buytenh@wantstofly.org> wrote:
> On Mon, Jul 12, 2010 at 10:59:29PM +0200, Karl Beldan wrote:
>
>> Hi,
>
> Hi Karl,
>
> Sorry, I didn't see your mail initially -- please CC me in the future.
>
>
>> I found the dsa code very handy to help manage a switch.
>
> Ah.  What particular part are you using?
>
>
The whole thing but the cascading stuff.
I could even reuse a tagging format almost as is!

>> Yet I was surprised I had to tweak the code to simply use the phy
>> layer state machine.
>
> You mean that net/dsa uses phy_attach() but not phy_start_machine() ?
> Have you seen problems arising from this?
>
>
I did not mean that, but I do not think there would be a problem,
since every in-tree driver provide their poll_link() to do the job of
the phylib's state_queue, unless one does not provide its poll_link(),
I guess this is what you had in mind.
What I had in mind in fact was the re-use of the phylib's interrupt
based code, in this situation poll_link() is not there, but there
replacing phy_attach() with phy_start_machine is not enough.
Those are not big changes, but the code seems to aim at such versatile
behavior (and more), I can only imagine it would be useful for the
plethora of boards embedding a switch.

>> And I don't see much activity in the code nor any discussion, e.g no
>> follow up to http://patchwork.ozlabs.org/patch/16578.
>>
>> So I was wondering if there was anybody playing with this code, or
>> having ideas about features to add (vlan/stp callbacks) ?
>
> As far as I know, the code currently in the kernel works well for what
> it intends to do (which is to just expose the switch ports), and I'm
> not aware of any bugs in it.
>
> That said, you're right in that there are several more features that
> the hardware supports that the software could be extended to handle.
>
> For one, I don't have access to any Marvell switch chip hardware
> anymore, so that limits my ability to play with this.  Also, the
> relevant documentation is under a rather restrictive license, so the
> only way I can see net/dsa support for Marvell parts improving is if
> there's pressure from a large enough customer to make this happen.
>
Now I understand, but still, I am surprised nobody else touched the
code, with all those switches in the embedded business.

> If this is about non-Marvell parts, I'd welcome adding support for
> those into net/dsa.  For one, I would really like to see Broadcom
> switch chip support added -- the documentation for those chips is
> under similarly restrictive licensing, though.
>
>

Thanks,

Karl

Re: net/dsa

[Lennert Buytenhek]

On Tue, Jul 20, 2010 at 11:28:19PM +0200, Karl Beldan wrote:

> >> I found the dsa code very handy to help manage a switch.
> >
> > Ah.  What particular part are you using?
> 
> The whole thing but the cascading stuff.
> I could even reuse a tagging format almost as is!

I meant, which silicon part, i.e. which hardware/chips?  Anything with
available data sheets?


> >> Yet I was surprised I had to tweak the code to simply use the phy
> >> layer state machine.
> >
> > You mean that net/dsa uses phy_attach() but not phy_start_machine() ?
> > Have you seen problems arising from this?
>
> I did not mean that, but I do not think there would be a problem,
> since every in-tree driver provide their poll_link() to do the job of
> the phylib's state_queue, unless one does not provide its poll_link(),
> I guess this is what you had in mind.
> What I had in mind in fact was the re-use of the phylib's interrupt
> based code, in this situation poll_link() is not there, but there
> replacing phy_attach() with phy_start_machine is not enough.

We cannot rely on the switch's interrupt pin being hooked up -- there
are many boards out where it's not wired up at all.  Therefore, polling
for link state changes is the only reliable and portable way.

(Of course, interrupt support can always be added, and that used
instead of polling if a load-time test shows that the interrupt pin
actually works.)


> Those are not big changes, but the code seems to aim at such versatile
> behavior (and more), I can only imagine it would be useful for the
> plethora of boards embedding a switch.

Although it supports Marvell chips only for now, net/dsa was written to
be able to handle other models of switch chips as well.  As I said, I
would love to see support for other switch chips added to it.


> > > So I was wondering if there was anybody playing with this code, or
> > > having ideas about features to add (vlan/stp callbacks) ?
> >
> > As far as I know, the code currently in the kernel works well for what
> > it intends to do (which is to just expose the switch ports), and I'm
> > not aware of any bugs in it.
> >
> > That said, you're right in that there are several more features that
> > the hardware supports that the software could be extended to handle.
> >
> > For one, I don't have access to any Marvell switch chip hardware
> > anymore, so that limits my ability to play with this.  Also, the
> > relevant documentation is under a rather restrictive license, so the
> > only way I can see net/dsa support for Marvell parts improving is if
> > there's pressure from a large enough customer to make this happen.
>
> Now I understand, but still, I am surprised nobody else touched the
> code, with all those switches in the embedded business.

Me too..

..then again, "embedded people" tend to hack up stuff in private
and ship whatever works -- they aren't exactly known for working with
upstream.

Re: net/dsa

[Karl Beldan]

http://www.mail-archive.com/uclinux-dist-devel@blackfin.uclinux.org/msg04218.html