It is not special from netlink view point. Just that we can omit from the
string representation without losing information.
On Wed, Jul 31, 2013 at 3:08 PM, Jesse Gross wrote:
> (0/0) is also an unmasked key.
>
> This is exactly my point. There should not be a sliver of a doubt in
> anyone's mi
We need to print (5/0) in order to how the unmasked key.
On Wed, Jul 31, 2013 at 2:08 PM, Jesse Gross wrote:
> This is debugging output, so it should print exactly what is received.
> If there are more compact ways of representing it then that is fine as
> long as it retains the same meaning.
>
(0/0) is also an unmasked key.
This is exactly my point. There should not be a sliver of a doubt in
anyone's mind as to whether 0 is a special value. It's not.
On Wed, Jul 31, 2013 at 3:05 PM, Andy Zhou wrote:
> We need to print (5/0) in order to how the unmasked key.
>
>
> On Wed, Jul 31, 2013
This is debugging output, so it should print exactly what is received.
If there are more compact ways of representing it then that is fine as
long as it retains the same meaning.
In addition, zero is no longer a special value so a value of (5/0)
should be treated the same as (0/0) but this isn't d
Yes, it is possible with more hacking on the test scripts. Omitting them
would make the output easier to read in general -- having more (0/0) does
not add more information. In general we are moving in a direction of not
output unnecessary information, removing output mask of 255.255.255.255,
for ex
Can't you just add skb_mark to the input?
On Wed, Jul 31, 2013 at 12:39 PM, Andy Zhou wrote:
> This helps to keep the test easy: Input is the same as output.
>
>
> On Wed, Jul 31, 2013 at 11:39 AM, Jesse Gross wrote:
>>
>> On Tue, Jul 30, 2013 at 7:49 PM, Andy Zhou wrote:
>> > Handling of missi
This helps to keep the test easy: Input is the same as output.
On Wed, Jul 31, 2013 at 11:39 AM, Jesse Gross wrote:
> On Tue, Jul 30, 2013 at 7:49 PM, Andy Zhou wrote:
> > Handling of missing attributes in netlink can be tricky and turns out
> > to be error prone. The value (savings in netlink
On Tue, Jul 30, 2013 at 7:49 PM, Andy Zhou wrote:
> Handling of missing attributes in netlink can be tricky and turns out
> to be error prone. The value (savings in netlink bandwidth) does not
> seem to be significant enough to justify allowing them. This patch
> series make both kernel and usersp
Hi Andy,
I think your plan to remove ambiguity is a good one.
On Tue, Jul 30, 2013 at 09:09:35PM -0700, Andy Zhou wrote:
> Simon, Thanks for the review.
> The intention of my patch is to always export those attributes to remove
> the ambiguity associated with interpreting missing attributes. Glad
Simon, Thanks for the review.
The intention of my patch is to always export those attributes to remove
the ambiguity associated with interpreting missing attributes. Glad to hear
this patch would work well with recirculation.
On Tue, Jul 30, 2013 at 8:54 PM, Simon Horman wrote:
> On Tue, Jul 30
On Tue, Jul 30, 2013 at 07:49:13PM -0700, Andy Zhou wrote:
> Handling of missing attributes in netlink can be tricky and turns out
> to be error prone. The value (savings in netlink bandwidth) does not
> seem to be significant enough to justify allowing them. This patch
> series make both kernel an
Handling of missing attributes in netlink can be tricky and turns out
to be error prone. The value (savings in netlink bandwidth) does not
seem to be significant enough to justify allowing them. This patch
series make both kernel and userspace always export priority and
skb_mark attribute. There wi
12 matches
Mail list logo
