> Out of curiosity: Are there fundamental reasons why ToR switches don't use
> the DSA model, or is it more historical?
Yes, there is a fundamental reason.
https://www.netdevconf.org/2.1/session.html?lunn_didelot_fainelli
DSA always has a host Ethernet interface connected to a port of the
> OK, so looks like DSA is actually what I need. I just didn't see a clear
> implementation path for e.g. ACL functions.
> Correct me if I'm wrong, to add support for ar8327 ACL or port rate control
> I should expand struct dsa_switch_ops, add appropriate infrastructure in
> netfilter/tc
On 09. nov. 2017 14:24, Andrew Lunn wrote:
What should also be considered is who is pushing swithdev and DSA
forward, and for what market.
Pure switchdev drivers is mostly being pushed forward for Top or Rack
switches. Big switches, 10G, 40G, 100G ports and lots of them. L3
routing, etc.
On 2017-11-09 20:08, Florian Fainelli wrote:
On 11/09/2017 09:24 AM, Andrew Lunn wrote:
The registers writing code is where? switchdev driver?
All I care about is that all the switch specific code should be in
one
place.
The switch specific code is in the switch specific driver.
Take a
On 2017-11-09 19:24, Andrew Lunn wrote:
The registers writing code is where? switchdev driver?
All I care about is that all the switch specific code should be in one
place.
The switch specific code is in the switch specific driver.
Take a look under drivers/net/dsa for the switches which are
On Thu, Nov 9, 2017 at 7:08 PM, Florian Fainelli wrote:
> if you are thinking about converting existing swconfig
> drivers from OpenWrt/LEDE into DSA, please do it! The conversion is
> reasonably simple even if the APIs do not exactly match.
I can confirm this :)
It's
On 11/09/2017 09:24 AM, Andrew Lunn wrote:
>> The registers writing code is where? switchdev driver?
>> All I care about is that all the switch specific code should be in one
>> place.
>
> The switch specific code is in the switch specific driver.
>
> Take a look under drivers/net/dsa for the
> The registers writing code is where? switchdev driver?
> All I care about is that all the switch specific code should be in one
> place.
The switch specific code is in the switch specific driver.
Take a look under drivers/net/dsa for the switches which are currently
supported by DSA.
On 2017-11-09 17:38, Andrew Lunn wrote:
>>Unless switchdev could be expanded to support other functions beyond
>>VLAN,
>>like port rate control, ACL, HW NAT (no switchdev L3 offload doesn't fit
>>this), etc.
>
>Switchdev allows offloading of TC. So port rate control would be
>implemented via TC.
> >>Unless switchdev could be expanded to support other functions beyond
> >>VLAN,
> >>like port rate control, ACL, HW NAT (no switchdev L3 offload doesn't fit
> >>this), etc.
> >
> >Switchdev allows offloading of TC. So port rate control would be
> >implemented via TC.
>
> That's interesting.
On 2017-11-09 15:24, Andrew Lunn wrote:
Although it could be a good thing to bring this to mainline, I'm kind
of
pessimistic about supporting such switches in DSA/switchdev. IMO
swconfig
does a better job for now.
I think the important point here is "... for now"
... as always, probably
> Although it could be a good thing to bring this to mainline, I'm kind of
> pessimistic about supporting such switches in DSA/switchdev. IMO swconfig
> does a better job for now.
I think the important point here is "... for now"
> Unless switchdev could be expanded to support other functions
On 2017-11-06 01:19, Linus Walleij wrote:
This adds a driver core for the Realtek SMI chips and a subdriver
for the RTL8366RB. I just added this chip simply because it is
all I can test.
The code is a massaged variant of the code that has been sitting
out-of-tree in OpenWRT for years in the
On Mon, Nov 6, 2017 at 12:59 AM, Andrew Lunn wrote:
> I'm wondering if this should be modelled as a normal MDIO bus? Put the
> driver as drivers/net/mdio-realtek.c?
I looked into it but couldn't find a good fit.
The MDIO bus makes much more sense since more than one vendor
is
Hi Linus
> +static int realtek_smi_read_reg(struct realtek_smi *smi, u32 addr, u32 *data)
> +{
> + unsigned long flags;
> + u8 lo = 0;
> + u8 hi = 0;
> + int ret;
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + realtek_smi_start(smi);
> +
> + /* send READ command */
>
This adds a driver core for the Realtek SMI chips and a subdriver
for the RTL8366RB. I just added this chip simply because it is
all I can test.
The code is a massaged variant of the code that has been sitting
out-of-tree in OpenWRT for years in the absence of a proper switch
subsystem. I have
16 matches
Mail list logo