From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Felix Fietkau <nbd@nbd.name>
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: Thu, 15 Jul 2021 23:36:26 +0200 [thread overview]
Message-ID: <20210715213626.GA19271@salvia> (raw)
In-Reply-To: <ceee6c30-adc1-3a79-31c3-983fe848699c@nbd.name>
On Wed, Jul 14, 2021 at 10:26:08AM +0200, Felix Fietkau wrote:
> On 2021-07-13 20:56, Pablo Neira Ayuso wrote:
[...]
> >> --- 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.
in a few steps:
1) Extend nft_dev_path_info() to deal with DEV_PATH_WDMA, it will
just actually fetch a pointer to structure that is allocated
by the driver.
- Update the net_device_path structure with this layout:
struct flow_action_wdma {
enum wdma_type type; // MTK_WDMA goes here
union {
struct {
...;
} mtk;
};
} wdma;
Add:
struct flow_action_wdma *wdma;
to net_device_path.
2) Pass on this pointer to structure to the nf_flow_route
wheelbarrow.
3) Store this information in the struct flow_offload_tuple,
in a new struct flow_offload_hw *field to store all hardware
offload specific information (not needed by software path). There
is already hw_outdev that can be placed there.
4) Add a FLOW_ACTION_WDMA action to the flow offload API to
pass on the flow_action_wdma structure.
It's a bit of work the first time to accomodate the requirements of
new API, but then all drivers will benefit from this.
It's also a bit of layering, but with more drivers in the tree, this
API can be simplified incrementally.
I can take a stab at it and send you a patch.
> 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.
It's simpler yes, but this results in two calls for
ndo_fill_forward_path, one from the core and another from the driver.
I think it's better there's a single point to call to
ndo_fill_forward_path for consolidation.
My proposal requires a bit more plumbing, but all drivers will
get the information that represents the offload in the same way.
next prev parent reply other threads:[~2021-07-15 21:36 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
2021-07-15 21:36 ` Pablo Neira Ayuso [this message]
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=20210715213626.GA19271@salvia \
--to=pablo@netfilter.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.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.