Hi Cong, Thanks for your responses so far.
> On 22 Mar 2019, at 23:09, Cong Wang <xiyou.wangc...@gmail.com> wrote: > > 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 will remove the functionality from conndscp that changes the conntrack mark, so that it only restores the mark into the diffserv field. So that I’m clear about which direction I should be headed: Bearing in mind that conndscp writes to the skb’s iphdr diffserv field and *not* skb->fwmark, do you still desire to see the dscp restoration code done as part of connmark. In other words NOT have a separate conndscp module? > > >>> >>> 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. I have a working copy/paste abomination example that creates an XT_CONNMARK_SAVEDSCP type function and will consult the netfilter devs for feedback. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
