netdev - Re: [PATCH v2 net-next] net: stmmac: Add support for U32 TC filter using Flexible RX Parser

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 4 May 2018 18:33:38 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Jose Abreu <Jose.Abreu@...opsys.com>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        Vitor Soares <Vitor.Soares@...opsys.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>
Subject: Re: [PATCH v2 net-next] net: stmmac: Add support for U32 TC filter
 using Flexible RX Parser

On Fri,  4 May 2018 10:01:38 +0100, Jose Abreu wrote:
> This adds support for U32 filter by using an HW only feature called
> Flexible RX Parser. This allow us to match any given packet field with a
> pattern and accept/reject or even route the packet to a specific DMA
> channel.
> 
> Right now we only support acception or rejection of frame and we only
> support simple rules. Though, the Parser has the flexibility of jumping to
> specific rules as an if condition so complex rules can be established.
> 
> This is only supported in GMAC5.10+.
> 
> The following commands can be used to test this code:
> 
> 	1) Setup an ingress qdisk:
> 	# tc qdisc add dev eth0 handle ffff: ingress
> 
> 	2) Setup a filter (e.g. filter by IP):
> 	# tc filter add dev eth0 parent ffff: protocol ip u32 match ip \
> 		src 192.168.0.3 skip_sw action drop
> 
> In every tests performed we always used the "skip_sw" flag to make sure
> only the RX Parser was involved.
> 
> Signed-off-by: Jose Abreu <joabreu@...opsys.com>
> Cc: David S. Miller <davem@...emloft.net>
> Cc: Joao Pinto <jpinto@...opsys.com>
> Cc: Vitor Soares <soares@...opsys.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@...com>
> Cc: Alexandre Torgue <alexandre.torgue@...com>
> Cc: Jakub Kicinski <kubakici@...pl>
> ---
> Changes from v1:
> 	- Follow Linux network coding style (David)
> 	- Use tc_cls_can_offload_and_chain0() (Jakub)

Thanks!

> @@ -4223,6 +4277,11 @@ int stmmac_dvr_probe(struct device *device,
>  	ndev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
>  			    NETIF_F_RXCSUM;
>  
> +	ret = stmmac_tc_init(priv, priv);
> +	if (!ret) {
> +		ndev->hw_features |= NETIF_F_HW_TC;
> +	}
> +
>  	if ((priv->plat->tso_en) && (priv->dma_cap.tsoen)) {
>  		ndev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
>  		priv->tso = true;

One more comment, but perhaps not a showstopper, it's considered good
practice to disallow clearing/disabling this flag while filters are
installed.  Driver should return -EBUSY from .ndo_set_features if TC
rules are offloaded and user wants to disable HW_TC feature flag.