On Thu, Mar 25, 2021 at 03:34, Vladimir Oltean wrote:
> On Wed, Mar 24, 2021 at 05:07:09PM +0100, Tobias Waldekranz wrote:
>> But even if the parser was enabled, it would never get anywhere since
>> the Ethertype would look like random garbage. Unless we have the soft
>> parser, but then it is not
On Wed, Mar 24, 2021 at 05:07:09PM +0100, Tobias Waldekranz wrote:
> But even if the parser was enabled, it would never get anywhere since
> the Ethertype would look like random garbage. Unless we have the soft
> parser, but then it is not the middle ground anymore :)
Garbage, true, but garbage wi
On Wed, Mar 24, 2021 at 17:08, Vladimir Oltean wrote:
> On Wed, Mar 24, 2021 at 04:02:52PM +0100, Tobias Waldekranz wrote:
>> On Wed, Mar 24, 2021 at 16:03, Vladimir Oltean wrote:
>> > On Tue, Mar 23, 2021 at 10:17:30PM +0100, Tobias Waldekranz wrote:
>> >> > I don't see any place in the network
On Wed, Mar 24, 2021 at 04:02:52PM +0100, Tobias Waldekranz wrote:
> On Wed, Mar 24, 2021 at 16:03, Vladimir Oltean wrote:
> > On Tue, Mar 23, 2021 at 10:17:30PM +0100, Tobias Waldekranz wrote:
> >> > I don't see any place in the network stack that recalculates the FCS if
> >> > NETIF_F_RXALL is s
On Wed, Mar 24, 2021 at 16:03, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 10:17:30PM +0100, Tobias Waldekranz wrote:
>> > I don't see any place in the network stack that recalculates the FCS if
>> > NETIF_F_RXALL is set. Additionally, without NETIF_F_RXFCS, I don't even
>> > know how could t
On Wed, Mar 24, 2021 at 04:03:17PM +0200, Vladimir Oltean wrote:
> I think there exists an intermediate approach between processing the
> frames on the RX queue and installing a soft parser.
I meant "RX error queue", sorry for the confusion.
On Tue, Mar 23, 2021 at 10:17:30PM +0100, Tobias Waldekranz wrote:
> > I don't see any place in the network stack that recalculates the FCS if
> > NETIF_F_RXALL is set. Additionally, without NETIF_F_RXFCS, I don't even
> > know how could the stack even tell a packet with bad FCS apart from one
> >
On Wed, Mar 24, 2021 at 02:01:14PM +0100, Tobias Waldekranz wrote:
> On Wed, Mar 24, 2021 at 13:34, Vladimir Oltean wrote:
> > On Wed, Mar 24, 2021 at 11:52:49AM +0100, Tobias Waldekranz wrote:
> >> >> This is the tragedy: I know for a fact that a DSA soft parser exists,
> >> >> but because of the
On Wed, Mar 24, 2021 at 13:34, Vladimir Oltean wrote:
> On Wed, Mar 24, 2021 at 11:52:49AM +0100, Tobias Waldekranz wrote:
>> >> This is the tragedy: I know for a fact that a DSA soft parser exists,
>> >> but because of the aforementioned maze of NDAs and license agreements
>> >> we, the community
On Wed, Mar 24, 2021 at 01:44, Andrew Lunn wrote:
>> This was my initial approach. It gets quite messy though. Since taggers
>> can be modules, there is no way of knowing if a supplied protocol name
>> is garbage ("asdf"), or just part of a module in an initrd that is not
>> loaded yet when you ar
On Wed, Mar 24, 2021 at 11:52:49AM +0100, Tobias Waldekranz wrote:
> >> This is the tragedy: I know for a fact that a DSA soft parser exists,
> >> but because of the aforementioned maze of NDAs and license agreements
> >> we, the community, cannot have nice things.
> >
> > Oh yeah? You can even cre
On Wed, Mar 24, 2021 at 01:15, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 10:17:30PM +0100, Tobias Waldekranz wrote:
>> On Tue, Mar 23, 2021 at 21:03, Vladimir Oltean wrote:
>> > On Tue, Mar 23, 2021 at 03:48:51PM +0100, Tobias Waldekranz wrote:
>> >> On Tue, Mar 23, 2021 at 13:35, Vladimir
> This was my initial approach. It gets quite messy though. Since taggers
> can be modules, there is no way of knowing if a supplied protocol name
> is garbage ("asdf"), or just part of a module in an initrd that is not
> loaded yet when you are probing the tree.
Hi Tobias
I don't think that is a
On Tue, Mar 23, 2021 at 10:17:30PM +0100, Tobias Waldekranz wrote:
> On Tue, Mar 23, 2021 at 21:03, Vladimir Oltean wrote:
> > On Tue, Mar 23, 2021 at 03:48:51PM +0100, Tobias Waldekranz wrote:
> >> On Tue, Mar 23, 2021 at 13:35, Vladimir Oltean wrote:
> >> > The netdev_uses_dsa thing is a bit tr
On Tue, Mar 23, 2021 at 21:03, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 03:48:51PM +0100, Tobias Waldekranz wrote:
>> On Tue, Mar 23, 2021 at 13:35, Vladimir Oltean wrote:
>> > The netdev_uses_dsa thing is a bit trashy, I think that a more polished
>> > version should rather set NETIF_F_R
On Tue, Mar 23, 2021 at 09:53, Florian Fainelli wrote:
> On 3/23/2021 7:49 AM, Tobias Waldekranz wrote:
>> On Tue, Mar 23, 2021 at 13:41, Andrew Lunn wrote:
>>> On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
All devices are capable of using regular DSA tags. Support for
>
On Tue, Mar 23, 2021 at 03:48:51PM +0100, Tobias Waldekranz wrote:
> On Tue, Mar 23, 2021 at 13:35, Vladimir Oltean wrote:
> > The netdev_uses_dsa thing is a bit trashy, I think that a more polished
> > version should rather set NETIF_F_RXALL for the DSA master, and have the
> > dpaa driver act up
On 3/23/2021 7:49 AM, Tobias Waldekranz wrote:
> On Tue, Mar 23, 2021 at 13:41, Andrew Lunn wrote:
>> On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
>>> All devices are capable of using regular DSA tags. Support for
>>> Ethertyped DSA tags sort into three categories:
>>>
>>>
On 3/23/2021 7:48 AM, Tobias Waldekranz wrote:
> On Tue, Mar 23, 2021 at 13:35, Vladimir Oltean wrote:
>> On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
>>> All devices are capable of using regular DSA tags. Support for
>>> Ethertyped DSA tags sort into three categories:
>>>
On Tue, Mar 23, 2021 at 13:41, Andrew Lunn wrote:
> On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
>> All devices are capable of using regular DSA tags. Support for
>> Ethertyped DSA tags sort into three categories:
>>
>> 1. No support. Older chips fall into this category.
>>
On Tue, Mar 23, 2021 at 13:35, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
>> All devices are capable of using regular DSA tags. Support for
>> Ethertyped DSA tags sort into three categories:
>>
>> 1. No support. Older chips fall into this category.
On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
> All devices are capable of using regular DSA tags. Support for
> Ethertyped DSA tags sort into three categories:
>
> 1. No support. Older chips fall into this category.
>
> 2. Full support. Datasheet explicitly supports configur
On Tue, Mar 23, 2021 at 01:35:22PM +0200, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
> > All devices are capable of using regular DSA tags. Support for
> > Ethertyped DSA tags sort into three categories:
> >
> > 1. No support. Older chips fall into
On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
> All devices are capable of using regular DSA tags. Support for
> Ethertyped DSA tags sort into three categories:
>
> 1. No support. Older chips fall into this category.
>
> 2. Full support. Datasheet explicitly supports configur
All devices are capable of using regular DSA tags. Support for
Ethertyped DSA tags sort into three categories:
1. No support. Older chips fall into this category.
2. Full support. Datasheet explicitly supports configuring the CPU
port to receive FORWARDs with a DSA tag.
3. Undocumented suppor
25 matches
Mail list logo
