On Fri, Mar 22, 2019 at 1:50 PM Kevin 'ldir' Darbyshire-Bryant <l...@darbyshire-bryant.me.uk> wrote: > > > > > On 22 Mar 2019, at 20:05, Cong Wang <xiyou.wangc...@gmail.com> wrote: > > > > On Fri, Mar 22, 2019 at 11:26 AM Kevin 'ldir' Darbyshire-Bryant > > <l...@darbyshire-bryant.me.uk> wrote: > >> > >> Hi Cong, > >> > >> Thanks for your questions. > >> > >>> On 22 Mar 2019, at 17:39, Cong Wang <xiyou.wangc...@gmail.com> wrote: > >>> > >>> Hello, > >>> > >>> On Fri, Mar 22, 2019 at 7:09 AM Kevin 'ldir' Darbyshire-Bryant > >>> <l...@darbyshire-bryant.me.uk> wrote: > >>>> > >>>> Conndscp is a new tc filter action module. It is designed to copy DSCPs > >>>> to conntrack marks and the reverse operation of conntrack mark contained > >>>> DSCPs to the diffserv field of suitable skbs. > >>>> > >>> > >>> Is it possible and feasible to integrate this into connmark? > >> > >> I started off coding it that way but quickly ran into my limitations with > >> netlink messaging and became frustrated. Aside from my own limitations, > >> conndscp ab/uses tcf_qstats requeues & overlimits to indicate > >> DSCP->MARK->DSCP operations and has been useful in proving DSCP/marking > >> operations are occurring in the right times/places. Integrating with > >> connmark which itself uses overlimits to indicate conntrack mark to > >> skb->mark restoration would lose that differentiation/confirmation/debug > >> ability. A possibility is to ab/use the drop count instead but I fear > >> that would cause confusion. > > > > This sounds problematic, why a flag/parameter doesn't work? > > > I don’t understand the question?
You said conndscp uses some stat to save some configuration information, that is, DSCP->MARK->DSCP operations. But configuration information is usually saved in a parameter struct or some priviate flag. So, I have to ask why a flag/parameter doesn't work for this case? And, you also implied this is a barrier for you to reuse connmark action. Am I misunderstanding anything here? > > > > >> > >>> Both are intended to retrieve information from conntrack and store > >>> it into skb. I know the name "connmark" already says it is a mark, > >>> while yours isn't, I still want to see if we can avoid code duplications. > >> > >> I understand your quest :-) I think conndscp does a bit more than > >> connmark. Conndscp is two way diffserv<-->conntrack mark operation. > >> connmark is a single way conntrack mark->skb.mark operation. > > > > I am not sure if it is a good idea to modify conntrack in TC, > > as conntrack doesn't even belong to TC. Retrieving information > > from conntrack and saving it to skb is fine, as we modify skb > > in many different ways. > > OK, this is why I wanted to ask as RFC before I went too far implementing > stuff. AFAIUI you’re saying it’s tc is okay to restore stuff from a connmark > but not to set/change the conntrack mark. So I need to find a legal place to > store a DSCP into a conntrack mark. Yes. I guess you should look into netfilter to modify any conntrack attribute, it is at least where conntrack belongs to. :) Thanks.
