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] [day] [month] [year] [list]

Message-ID: <c34b4b58-55a9-0952-f66d-0680dc768b3b@synopsys.com>
Date:   Mon, 7 May 2018 11:02:14 +0100
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Jakub Kicinski <kubakici@...pl>,
        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

Hi Jakub, David,

On 05-05-2018 02:33, Jakub Kicinski wrote:
> 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.

I can do that but I saw in Patchwork that patch was already
marked as accepted, David sent me no confirmation though.

David,
Shall I respin or send a follow up patch?

Thanks and Best Regards,
Jose Miguel Abreu