On 6/18/2019 7:03 PM, Cong Wang wrote: > On Fri, Jun 14, 2019 at 12:24 PM Marcelo Ricardo Leitner > <marcelo.leit...@gmail.com> wrote: >> On Fri, Jun 14, 2019 at 11:07:37AM -0700, Cong Wang wrote: >>> On Tue, Jun 11, 2019 at 9:44 AM Marcelo Ricardo Leitner >>> <marcelo.leit...@gmail.com> wrote: >>>> I had suggested to let act_ct handle the above as well, as there is a >>>> big chunk of code on both that is pretty similar. There is quite some >>>> boilerplate for interfacing with conntrack which is duplicated. >>> Why do you want to mix retrieving conntrack info with executing >>> conntrack? >> To save on the heavy boilerplate for interfacing with conntrack. >> >>> They are totally different things to me, act_ctinfo merely retrieves >>> information from conntrack, while this one, act_ct, is supposed to >>> move packets to conntrack. >> Seems we have a different understanding for "move packets to >> conntrack": conntrack will not consume the packets after this. >> But after act_ct is executed, if not with the clear flag, skb will now >> have the skb->_nfct entry available, on which flower then will be able >> to match. So in essence, it is also fetching information from >> conntrack. > Interesting. Is it because cls_flower uses conntrack for flow dissection? > What's the reason behind? > > Again, I am still not convinced to do L3 operations in L2, skb->_nfct > belongs to conntrack which is L3, no matter the packet is consumed > or not. > > Thanks.
I'm not sure what you mean, the reason behind what? We use conntrack to track, mark the packet with conntrack info, and execute nat, then we push the headers back to continue processing the next action. This action will probably be followed by goto chain or reclassify and then cls_flower can be used to match on conntrack state and metadata via the new flow dissector change.
