On Fri, Mar 22, 2019 at 3:06 PM Kevin 'ldir' Darbyshire-Bryant <l...@darbyshire-bryant.me.uk> wrote: > > > > > On 22 Mar 2019, at 21:31, Cong Wang <xiyou.wangc...@gmail.com> wrote: > > > > 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? > > Ahh! I understand the question, apologies if I was not clear. conndscp like > connmark reports some status information back to tc via tcf_qstats structure. > connmark uses ‘overlimits’ to report the number of marks restored from > conntrack->mark to skb->mark. conndscp uses ‘overlimits’ and ‘requeues’ to > report status about how many marks it has restored/set. e.g.
I see, I didn't know this, but it is not hard to add a connmark specific stat for this, I don't know why it has to reuse 'overlimit', perhaps just to save some memory space. Unless you have legitimate reasons, you don't have to reuse it. It is just confusing. > > > > I guess you should look into netfilter to modify any conntrack attribute, > > it is at least where conntrack belongs to. :) > > So I wonder if an XT_CONNMARK_SAVEDSCP option in xt_connmark would be more > acceptable? I think so, but I have to say I am not a netfilter expert. You probably want to check it with netfilter developers too. Thanks.
