All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tobias Waldekranz <tobias@waldekranz.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: davem@davemloft.net, kuba@kernel.org, andrew@lunn.ch,
	vivien.didelot@gmail.com, f.fainelli@gmail.com,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next] net: dsa: mv88e6xxx: Allow dynamic reconfiguration of tag protocol
Date: Thu, 25 Mar 2021 09:04:01 +0100	[thread overview]
Message-ID: <87k0pvlkwe.fsf@waldekranz.com> (raw)
In-Reply-To: <20210325013432.muugsogq4mzmalpd@skbuf>

On Thu, Mar 25, 2021 at 03:34, Vladimir Oltean <olteanv@gmail.com> 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 the middle ground anymore :)
>
> Garbage, true, but garbage with enough entropy to allow for some sort of
> RFS (ideally you can get the source port field from the DSA tag into the
> area covered by the n-tuple on which the master performs hashing). This
> is the way in which the switches inside NXP LS1028A and T1040 work.

I see what you are saying. Any given flow would still have the same
not-really-an-Ethertype.

>> I suppose you would like to test for netdev_uses_dsa_and_violates_8023,
>> that way you could still do RSS on DSA devices using regular 1Q-tags for
>> example. Do we want to add this property to the taggers so that we do
>> not degrade performance for any existing users?
>
> Yes, so T1040 is one such example of device that would be negatively
> affected by this change. There isn't a good solution to solve all
> problems: there will be some Marvell switches which can't operate in
> EDSA mode, and there will be some DSA masters that can't parse Marvell
> DSA tags. Eventually all possible combinations of workarounds will have
> to be implemented. But for now, I think I prefer to see the simplest
> one, which has just become the one based on device tree.

Alright, it seems like everyone agrees then. I will look into it.

Just to avoid a DenverCoder9 situation; I tried changing the NIA in
FMBM_RFNE like you suggested:

8< ---

diff --git a/drivers/net/ethernet/freescale/fman/fman_port.c b/drivers/net/ethernet/freescale/fman/fman_port.c
index d9baac0dbc7d..5aa5b4068f2d 100644
--- a/drivers/net/ethernet/freescale/fman/fman_port.c
+++ b/drivers/net/ethernet/freescale/fman/fman_port.c
@@ -543,7 +543,7 @@ static int init_bmi_rx(struct fman_port *port)
        /* NIA */
        tmp = (u32)cfg->rx_fd_bits << BMI_NEXT_ENG_FD_BITS_SHIFT;
 
-       tmp |= NIA_ENG_HWP;
+       tmp |= NIA_ENG_BMI | NIA_BMI_AC_ENQ_FRAME;
        iowrite32be(tmp, &regs->fmbm_rfne);
 
        /* Parser Next Engine NIA */

8< ---

From what I can tell, this works as expected. TO_CPUs from port 8 can
ingress the device with this in place.

  reply	other threads:[~2021-03-25  8:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-23 10:23 [PATCH net-next] net: dsa: mv88e6xxx: Allow dynamic reconfiguration of tag protocol Tobias Waldekranz
2021-03-23 11:35 ` Vladimir Oltean
2021-03-23 12:32   ` Andrew Lunn
2021-03-23 14:48   ` Tobias Waldekranz
2021-03-23 16:30     ` Florian Fainelli
2021-03-23 19:03     ` Vladimir Oltean
2021-03-23 21:17       ` Tobias Waldekranz
2021-03-23 23:15         ` Vladimir Oltean
2021-03-24 10:52           ` Tobias Waldekranz
2021-03-24 11:34             ` Vladimir Oltean
2021-03-24 13:01               ` Tobias Waldekranz
2021-03-24 13:24                 ` Vladimir Oltean
2021-03-24 14:03         ` Vladimir Oltean
2021-03-24 14:10           ` Vladimir Oltean
2021-03-24 15:02           ` Tobias Waldekranz
2021-03-24 15:08             ` Vladimir Oltean
2021-03-24 16:07               ` Tobias Waldekranz
2021-03-25  1:34                 ` Vladimir Oltean
2021-03-25  8:04                   ` Tobias Waldekranz [this message]
2021-03-23 12:41 ` Andrew Lunn
2021-03-23 14:49   ` Tobias Waldekranz
2021-03-23 16:53     ` Florian Fainelli
2021-03-23 20:50       ` Tobias Waldekranz
2021-03-24  0:44     ` Andrew Lunn
2021-03-24 12:53       ` Tobias Waldekranz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0pvlkwe.fsf@waldekranz.com \
    --to=tobias@waldekranz.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.