On Thu, Apr 24, 2014 at 4:14 PM, Ben Pfaff <b...@nicira.com> wrote: > On Thu, Apr 24, 2014 at 4:01 PM, Jesse Gross <je...@nicira.com> wrote: >> On Thu, Apr 24, 2014 at 3:32 PM, Ben Pfaff <b...@nicira.com> wrote: >>> On Thu, Apr 24, 2014 at 02:57:28PM -0700, Jesse Gross wrote: >>>> I suppose the other possibility is to pass some kind of flag attribute >>>> with messages indicating that this is a test probe and would silence >>>> logging. Existing kernels would ignore this so they would still log >>>> but the behavior would be otherwise unchanged. >>> >>> That makes me nervous--it poses the temptation of changing behavior in >>> some other way, not just log-wise. >> >> I agree. I'm not sure what that change would be but it seems generally >> better if the kernel was completely oblivious to the fact that it is >> being tested so there is no possibility of a behavior difference. > > In this particular case, I think we could silence it by just having userspace > not probe the Linux datapath for features that we know it won't have. That > is, we know that we're not ever going to upstream MPLS to Linux with > attribute number 62, so we might as well skip the probe for dpif-linux.
That's true I guess but we already have another example since we now probe for recirculation. I don't think there is such an escape hatch for that case, so we probably need a more general solution. I know that logging at a level that is always turned on has been useful in debugging traffic that is rare and hard to reproduce, so I'm a little hesitant to turn that down. However, I don't have any other ideas beyond the first two that I listed. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
