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: 17+ 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 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).