On 2022/4/27 23:55, Pablo Neira Ayuso wrote: > On Wed, Apr 27, 2022 at 11:28:16PM +0800, wenxu wrote: >> On 2022/4/27 22:10, Pablo Neira Ayuso wrote: >>> On Tue, Apr 05, 2022 at 10:38:35AM -0400, wenx05124561@xxxxxxx wrote: >>>> From: wenxu <wenxu@xxxxxxxxxxxxxxx> >>>> >>>> This patch put the vlan dev process in the FLOW_OFFLOAD_XMIT_DIRECT >>>> mode. Xmit the packet with vlan can offload to the real dev directly. >>>> >>>> It can support all kinds of VLAN dev path: >>>> br0.100-->br0(vlan filter enable)-->eth >>>> br0(vlan filter enable)-->eth >>>> br0(vlan filter disable)-->eth.100-->eth >>> I assume this eth is a bridge port. >> Yes it is. And it also can support the case without bridge as following. >> >> eth.100-->eth. >> >>>> The packet xmit and recv offload to the 'eth' in both original and >>>> reply direction. >>> This is an enhancement or fix? >> It's an enhancement and it make the vlan packet can offload through the real dev. > What's the benefit from the existing approach? For the simplest case eth.100 base on eth eth.100 and ethx are route interface. Without this patch. The packet outgoing path from eth --- > ethx The packet incoming path from ethx ----> eth.100---> eth With this patch The packet incoming path from ethx (direct to)---> eth, it is the same with outgoing. > >>> Is this going to work for VLAN + PPP? >>> >>> Would you update tools/testing/selftests/netfilter/nft_flowtable.sh to >>> cover bridge filtering usecase? It could be done in a follow up patch. >> I will do for both if this patch reivew ok . > OK.
