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.
