All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@nbd.name>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	ryder.lee@mediatek.com
Subject: Re: [RFC 3/7] net: ethernet: mtk_eth_soc: implement flow offloading to WED devices
Date: Wed, 14 Jul 2021 10:26:08 +0200	[thread overview]
Message-ID: <ceee6c30-adc1-3a79-31c3-983fe848699c@nbd.name> (raw)
In-Reply-To: <20210713185641.GB26070@salvia>


On 2021-07-13 20:56, Pablo Neira Ayuso wrote:
> On Tue, Jul 13, 2021 at 06:07:41PM +0200, Felix Fietkau wrote:
>> This allows hardware flow offloading from Ethernet to WLAN on MT7622 SoC
>> 
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> ---
>>  drivers/net/ethernet/mediatek/mtk_ppe.c       | 18 +++++
>>  drivers/net/ethernet/mediatek/mtk_ppe.h       | 14 ++--
>>  .../net/ethernet/mediatek/mtk_ppe_offload.c   | 67 ++++++++++++-------
>>  include/linux/netdevice.h                     |  7 ++
>>  net/core/dev.c                                |  4 ++
>>  5 files changed, 78 insertions(+), 32 deletions(-)
>> 
>> diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
>> index 3ad10c793308..472bcd3269a7 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_ppe.c
>> +++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
>> @@ -329,6 +329,24 @@ int mtk_foe_entry_set_pppoe(struct mtk_foe_entry *entry, int sid)
>>  	return 0;
>>  }
>>  
>> +int mtk_foe_entry_set_wdma(struct mtk_foe_entry *entry, int wdma_idx, int txq,
>> +			   int bss, int wcid)
>> +{
>> +	struct mtk_foe_mac_info *l2 = mtk_foe_entry_l2(entry);
>> +	u32 *ib2 = mtk_foe_entry_ib2(entry);
>> +
>> +	*ib2 &= ~MTK_FOE_IB2_PORT_MG;
>> +	*ib2 |= MTK_FOE_IB2_WDMA_WINFO;
>> +	if (wdma_idx)
>> +		*ib2 |= MTK_FOE_IB2_WDMA_DEVIDX;
>> +
>> +	l2->vlan2 = FIELD_PREP(MTK_FOE_VLAN2_WINFO_BSS, bss) |
>> +		    FIELD_PREP(MTK_FOE_VLAN2_WINFO_WCID, wcid) |
>> +		    FIELD_PREP(MTK_FOE_VLAN2_WINFO_RING, txq);
>> +
>> +	return 0;
>> +}
>> +
>>  static inline bool mtk_foe_entry_usable(struct mtk_foe_entry *entry)
>>  {
>>  	return !(entry->ib1 & MTK_FOE_IB1_STATIC) &&
>> diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.h b/drivers/net/ethernet/mediatek/mtk_ppe.h
>> index 242fb8f2ae65..df8ccaf48171 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_ppe.h
>> +++ b/drivers/net/ethernet/mediatek/mtk_ppe.h
>> @@ -48,9 +48,9 @@ enum {
>>  #define MTK_FOE_IB2_DEST_PORT		GENMASK(7, 5)
>>  #define MTK_FOE_IB2_MULTICAST		BIT(8)
>>  
>> -#define MTK_FOE_IB2_WHNAT_QID2		GENMASK(13, 12)
>> -#define MTK_FOE_IB2_WHNAT_DEVIDX	BIT(16)
>> -#define MTK_FOE_IB2_WHNAT_NAT		BIT(17)
>> +#define MTK_FOE_IB2_WDMA_QID2		GENMASK(13, 12)
>> +#define MTK_FOE_IB2_WDMA_DEVIDX		BIT(16)
>> +#define MTK_FOE_IB2_WDMA_WINFO		BIT(17)
>>  
>>  #define MTK_FOE_IB2_PORT_MG		GENMASK(17, 12)
>>  
>> @@ -58,9 +58,9 @@ enum {
>>  
>>  #define MTK_FOE_IB2_DSCP		GENMASK(31, 24)
>>  
>> -#define MTK_FOE_VLAN2_WHNAT_BSS		GEMMASK(5, 0)
>> -#define MTK_FOE_VLAN2_WHNAT_WCID	GENMASK(13, 6)
>> -#define MTK_FOE_VLAN2_WHNAT_RING	GENMASK(15, 14)
>> +#define MTK_FOE_VLAN2_WINFO_BSS		GENMASK(5, 0)
>> +#define MTK_FOE_VLAN2_WINFO_WCID	GENMASK(13, 6)
>> +#define MTK_FOE_VLAN2_WINFO_RING	GENMASK(15, 14)
>>  
>>  enum {
>>  	MTK_FOE_STATE_INVALID,
>> @@ -281,6 +281,8 @@ int mtk_foe_entry_set_ipv6_tuple(struct mtk_foe_entry *entry,
>>  int mtk_foe_entry_set_dsa(struct mtk_foe_entry *entry, int port);
>>  int mtk_foe_entry_set_vlan(struct mtk_foe_entry *entry, int vid);
>>  int mtk_foe_entry_set_pppoe(struct mtk_foe_entry *entry, int sid);
>> +int mtk_foe_entry_set_wdma(struct mtk_foe_entry *entry, int wdma_idx, int txq,
>> +			   int bss, int wcid);
>>  int mtk_foe_entry_commit(struct mtk_ppe *ppe, struct mtk_foe_entry *entry,
>>  			 u16 timestamp);
>>  int mtk_ppe_debugfs_init(struct mtk_ppe *ppe);
>> diff --git a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
>> index b5f68f66d42a..00b1d06f60d1 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
>> +++ b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
>> @@ -10,6 +10,7 @@
>>  #include <net/pkt_cls.h>
>>  #include <net/dsa.h>
>>  #include "mtk_eth_soc.h"
>> +#include "mtk_wed.h"
>>  
>>  struct mtk_flow_data {
>>  	struct ethhdr eth;
>> @@ -39,6 +40,7 @@ struct mtk_flow_entry {
>>  	struct rhash_head node;
>>  	unsigned long cookie;
>>  	u16 hash;
>> +	s8 wed_index;
>>  };
>>  
>>  static const struct rhashtable_params mtk_flow_ht_params = {
>> @@ -127,35 +129,38 @@ mtk_flow_mangle_ipv4(const struct flow_action_entry *act,
>>  }
>>  
>>  static int
>> -mtk_flow_get_dsa_port(struct net_device **dev)
>> +mtk_flow_set_output_device(struct mtk_eth *eth, struct mtk_foe_entry *foe,
>> +			   struct net_device *dev, const u8 *dest_mac,
>> +			   int *wed_index)
>>  {
>> -#if IS_ENABLED(CONFIG_NET_DSA)
>> -	struct dsa_port *dp;
>> -
>> -	dp = dsa_port_from_netdev(*dev);
>> -	if (IS_ERR(dp))
>> -		return -ENODEV;
>> -
>> -	if (dp->cpu_dp->tag_ops->proto != DSA_TAG_PROTO_MTK)
>> -		return -ENODEV;
>> +	struct net_device_path_ctx ctx = {
>> +		.dev    = dev,
>> +		.daddr  = dest_mac,
>> +	};
>> +	struct net_device_path path = {};
>> +	int pse_port;
>>  
>> -	*dev = dp->cpu_dp->master;
>> +	if (!dev->netdev_ops->ndo_fill_forward_path ||
>> +	    dev->netdev_ops->ndo_fill_forward_path(&ctx, &path) < 0)
>> +		path.type = DEV_PATH_ETHERNET;
> 
> Maybe expose this through flow offload API so there is no need to call
> ndo_fill_forward_path again from the driver?
Can you give me a pseudo-code example? I'm not sure how you want it to
be exposed through the flow offload API.
To me it seems easier and cleaner to just have a single
ndo_fill_forward_path call for the final output device to check the
device types that don't have any corresponding sw offload.

>> -	return dp->index;
>> -#else
>> -	return -ENODEV;
>> -#endif
>> -}
>> -
>> -static int
>> -mtk_flow_set_output_device(struct mtk_eth *eth, struct mtk_foe_entry *foe,
>> -			   struct net_device *dev)
>> -{
>> -	int pse_port, dsa_port;
>> +	switch (path.type) {
>> +	case DEV_PATH_DSA:
> 
> This DSA update is not related, right?
I consider it related. Since I'm calling ndo_fill_forward_path now, it's
better to use it for both DSA and WLAN instead of having independent checks.

- Felix

  reply	other threads:[~2021-07-14  8:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13 16:07 [RFC 0/7] Ethernet->WLAN hardware flow offloading support on MT7622 Felix Fietkau
2021-07-13 16:07 ` [RFC 1/7] mac80211: add support for .ndo_fill_forward_path Felix Fietkau
2021-07-13 16:46   ` Johannes Berg
2021-07-13 21:18   ` kernel test robot
2021-07-13 21:18   ` kernel test robot
2021-07-13 16:07 ` [RFC 2/7] net: ethernet: mtk_eth_soc: add support for Wireless Ethernet Dispatch (WED) Felix Fietkau
2021-07-13 18:31   ` Andrew Lunn
2021-07-14  8:03     ` Felix Fietkau
2021-07-13 16:07 ` [RFC 3/7] net: ethernet: mtk_eth_soc: implement flow offloading to WED devices Felix Fietkau
2021-07-13 18:40   ` Pablo Neira Ayuso
2021-07-14  8:21     ` Felix Fietkau
2021-07-13 18:56   ` Pablo Neira Ayuso
2021-07-14  8:26     ` Felix Fietkau [this message]
2021-07-15 21:36       ` Pablo Neira Ayuso
2021-07-16  6:09         ` Felix Fietkau
2021-07-13 16:07 ` [RFC 4/7] mt76: dma: add wrapper macro for accessing queue registers Felix Fietkau
2021-07-13 16:07 ` [RFC 5/7] mt76: make number of tokens configurable dynamically Felix Fietkau
2021-07-13 16:07 ` [RFC 6/7] mt76: mt7915: remove irq parameter from mt7915_mmio_init Felix Fietkau
2021-07-13 16:07 ` [RFC 7/7] mt76: mt7915: add Wireless Ethernet Dispatch support Felix Fietkau
2021-07-13 19:41   ` kernel test robot
2021-07-13 23:30   ` kernel test robot

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=ceee6c30-adc1-3a79-31c3-983fe848699c@nbd.name \
    --to=nbd@nbd.name \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=ryder.lee@mediatek.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.