On 12/08/2018 12:00 PM, Andrew Lunn wrote:
> On Sat, Dec 08, 2018 at 05:23:25AM +0100, Marek Vasut wrote:
>> On 12/08/2018 01:13 AM, tristram...@microchip.com wrote:
Do you have a git tree with all the KSZ patches based on -next
somewhere, so I don't have to look for them in random MLs ?
On 12/08/2018 12:00 PM, Andrew Lunn wrote:
> On Sat, Dec 08, 2018 at 05:23:25AM +0100, Marek Vasut wrote:
>> On 12/08/2018 01:13 AM, tristram...@microchip.com wrote:
Do you have a git tree with all the KSZ patches based on -next
somewhere, so I don't have to look for them in random MLs ?
On Sat, Dec 08, 2018 at 05:23:25AM +0100, Marek Vasut wrote:
> On 12/08/2018 01:13 AM, tristram...@microchip.com wrote:
> >> Do you have a git tree with all the KSZ patches based on -next
> >> somewhere, so I don't have to look for them in random MLs ?
> >
> > I just sent it this Monday and the su
On 12/08/2018 01:13 AM, tristram...@microchip.com wrote:
>> Do you have a git tree with all the KSZ patches based on -next
>> somewhere, so I don't have to look for them in random MLs ?
>
> I just sent it this Monday and the subject for that patch is
> "[PATCH RFC 6/6] net: dsa: microchip: Add swi
> Do you have a git tree with all the KSZ patches based on -next
> somewhere, so I don't have to look for them in random MLs ?
I just sent it this Monday and the subject for that patch is
"[PATCH RFC 6/6] net: dsa: microchip: Add switch offload forwarding support."
> > I think if you do this without setting offload_fwd_mark you will
> > receive duplicate frame.
>
> I don't think it will, at least not in the normal case. The hardware
> should know the egress port, so there is no need to forward a copy to
> the CPU. The only time it should forward to the CPU i
> >> If two ports are in the same bridge and in forwarding state, the packets
> >> must be able to pass between them in both directions. The current code
> >> only configures this bridge membership for a port newly added to the
> >> bridge, but does not update all the other ports. Thus, ingress pac
> I think if you do this without setting offload_fwd_mark you will
> receive duplicate frame.
I don't think it will, at least not in the normal case. The hardware
should know the egress port, so there is no need to forward a copy to
the CPU. The only time it should forward to the CPU is when the e
On 12/07/2018 08:37 PM, tristram...@microchip.com wrote:
>> If two ports are in the same bridge and in forwarding state, the packets
>> must be able to pass between them in both directions. The current code
>> only configures this bridge membership for a port newly added to the
>> bridge, but does
On 12/7/18 11:37 AM, tristram...@microchip.com wrote:
>> If two ports are in the same bridge and in forwarding state, the packets
>> must be able to pass between them in both directions. The current code
>> only configures this bridge membership for a port newly added to the
>> bridge, but does not
> If two ports are in the same bridge and in forwarding state, the packets
> must be able to pass between them in both directions. The current code
> only configures this bridge membership for a port newly added to the
> bridge, but does not update all the other ports. Thus, ingress packets
> on th
If two ports are in the same bridge and in forwarding state, the packets
must be able to pass between them in both directions. The current code
only configures this bridge membership for a port newly added to the
bridge, but does not update all the other ports. Thus, ingress packets
on the new port
12 matches
Mail list logo
