[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <449a5603-80e9-ad7d-5c02-bf57558f9603@ucloud.cn>
Date: Mon, 29 Jul 2019 15:18:03 +0800
From: wenxu <wenxu@...oud.cn>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc: pablo@...filter.org, fw@...len.de, netfilter-devel@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH net-next v4 2/3] flow_offload: Support get default block
from tc immediately
On 7/29/2019 12:42 PM, Jakub Kicinski wrote:
> On Mon, 29 Jul 2019 10:43:56 +0800, wenxu wrote:
>> On 7/29/2019 4:16 AM, Jakub Kicinski wrote:
>>> I don't know the nft code, but it seems unlikely it wouldn't have the
>>> same problem/need..
>> nft don't have the same problem. The offload rule can only attached
>> to offload base chain.
>>
>> Th offload base chain is created after the device driver loaded (the
>> device exist).
> For indirect blocks the block is on the tunnel device and the offload
> target is another device. E.g. you offload rules from a VXLAN device
> onto the ASIC. The ASICs driver does not have to be loaded when VXLAN
> device is created.
>
> So I feel like either the chain somehow directly references the offload
> target (in which case the indirect infrastructure with hash lookup etc
> is not needed for nft), or indirect infra is needed, and we need to take
> care of replays.
I think the nft is different with tc.
In tc case we can create vxlan device add a ingress qdisc with a block success
Then the ASIC driver loaded, then register the vxlan indr-dev and get the block
adn replay it to hardware
But in the nft case, The base chain flags with offload. Create an offload netdev
base chain on vxlan device will fail if there is no indr-device to offload.
Powered by blists - more mailing lists