Jarno and I just talked and agreed that it's probably finally time to
introduce some capabilities attributes. This would allow us to avoid
probing altogether and therefore avoid the logging issues.
On Fri, Apr 25, 2014 at 11:59 AM, Andy Zhou wrote:
> How about we skip logging each unexpected key
How about we skip logging each unexpected key attributes once? We can
use a u64 bit fields to keep track the flow key attributes in the
kernel module.
On Thu, Apr 24, 2014 at 6:30 PM, Jesse Gross wrote:
> On Thu, Apr 24, 2014 at 4:30 PM, Jarno Rajahalme
> wrote:
>>
>> On Apr 24, 2014, at 3:32
On Thu, Apr 24, 2014 at 4:30 PM, Jarno Rajahalme wrote:
>
> On Apr 24, 2014, at 3:32 PM, Ben Pfaff 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 p
Jesse, Ben, Jarno et. al,
This message although harmless can be confusing for developers who are
introducing new functionality and testing it on the datapath. When I
first turned on logging and saw it, I thought it was my bug until I
found saw it in the master branch.
I will take no action
On Apr 24, 2014, at 3:32 PM, Ben Pfaff 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
On Thu, Apr 24, 2014 at 4:14 PM, Ben Pfaff wrote:
> On Thu, Apr 24, 2014 at 4:01 PM, Jesse Gross wrote:
>> On Thu, Apr 24, 2014 at 3:32 PM, Ben Pfaff 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 attribut
On Thu, Apr 24, 2014 at 4:01 PM, Jesse Gross wrote:
> On Thu, Apr 24, 2014 at 3:32 PM, Ben Pfaff 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
On Thu, Apr 24, 2014 at 3:32 PM, Ben Pfaff 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 igno
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
The cleanest way seems to be to just reduce the default log level for
these messages so they don't pop up normally. I think we talked about
this before and were concerned about debugging when problems show up
at runtime other than developer testing.
I suppose the other possibility is to pass some
I am sure it can be done and most likely involving some netlink
changes. Since netlink message design is your forte, any suggestions?
On Thu, Apr 24, 2014 at 2:22 PM, Jesse Gross wrote:
> That's a good point, I didn't think about that. I wonder if there is a
> way to avoid the error message in t
That's a good point, I didn't think about that. I wonder if there is a
way to avoid the error message in these cases since it's likely to
cause confusion given that it is logged by default.
On Thu, Apr 24, 2014 at 1:57 PM, Andy Zhou wrote:
> Whenever we instantiate a new ofproto (i.e. bridge), we
Whenever we instantiate a new ofproto (i.e. bridge), we probe datapath
to detect if it supports MPLS, and if yes, how many labels it can
support. The probing produces similar error messages on my system.
It should only appear when you add the bridge, but not afterwards.
On Thu, Apr 24, 2014 at 12
On 4/24/2014 1:47 PM, Jesse Gross wrote:
On Thu, Apr 24, 2014 at 8:38 AM, Thomas F Herbert
wrote:
Hi,
I think there is a problem with parsing out the OVS ATTRIBUTE nesting in the
NL message in the datapath and I am having trouble finding the cause. I
think the nl msg is built up wrong in the c
On Thu, Apr 24, 2014 at 8:38 AM, Thomas F Herbert
wrote:
> Hi,
>
> I think there is a problem with parsing out the OVS ATTRIBUTE nesting in the
> NL message in the datapath and I am having trouble finding the cause. I
> think the nl msg is built up wrong in the case of the vlan push action.
>
> I
Hi,
I think there is a problem with parsing out the OVS ATTRIBUTE nesting in
the NL message in the datapath and I am having trouble finding the
cause. I think the nl msg is built up wrong in the case of the vlan push
action.
I first saw the problem while testing my patch for 802.1ad. However
16 matches
Mail list logo
