Hello, world!
Most of the maillists I'm in have the name on the Subject of all
emails in the format [] and this does not cause any issues for
anyone as far as I know.
For the record, I consider adding subject tags by mailing lists quite
annoying.
I sort each list to a separate folder
Hello!
Well, i don't know why kernel device routes are not imported in 'learn'
mode and instead direct protocol is used. Some of these reasons are
probably lost in the past (like in ancient Linux where device routes
have to be generated by user), another possible reason is that you still
Hello!
MJ, any comment on this list code and pointer aliasing?
I have also convinced myself that the code is correct.
However, as the years go, I more and more feel that saving a single
pointer in the list head is not worth the trickiness it takes.
My more recent programs mostly use a
Hello!
IMHO functions are more general that filters, i don't really see why there
are explicit named filters here. One minor advantage is that named filters
are displayed in 'show protocols all'.
One possible use is calling such filters from the CLI.
Have a
Hello!
This can help CLI interaction (and it is good as temporary solution),
but does not decrease time needed for dispatching flapping sessions
(particularly if there are many of them).
If you introduce priorities in the event loop, you can make sure that
flapping sessions cannot disrupt
Hello!
the limit to 15 characters for interface names is used all over bird
(look at 'struct iface' in nest/iface.h), as this is the limit imposed
by most Unix APIs, so I didn't see a reason not to use this limit.
Actually, it is not all over bird, but only in nest/iface.h (try grepping
for
Ahoj!
commit ee3256fe1cb3e429de22e7c50a0826aaa4dc7a73
Author: Ondrej Zajicek santi...@crfreenet.org
Date: Sat Oct 1 10:28:34 2011 +0200
Multiprotocol core support.
The patch from Alexander V. Chernikov.
Overall, the multiprotocol core looks good, there is a couple of minor
Hello, world!\n
I was wondering whether an include general option could be implemented as
to segment large BIRD configuration files to smaller parts, a lá BIND. This
should be trivial to implement I suppose, and could really help with
scripting and clarity.
At the dawn of time, when we
Hi!
Yes, static protocol has time complexity O(n^2) for reconfiguration,
so reconfiguration is slow for thousands of routes.
FIB could be used and i will probably fix that in that way.
Either that, or just sort the lists.
Have a nice fortnight
--
Martin `MJ'
Hello!
I'd like to ask you a quick question.
I'm working on a BIRD looking glass script and what I need is an
exact uptime of BGP session. sh protocols all doesn't seem to be
particularly useful as it isn't accurate enough (e.g. session is up
since 18May)
Is there a simple way to get more
Hello!
BGP peer group:
What exactly this should solve? If just common defaults, then i think
that with common filters and copy/paste in editor (or config file
generated by a script) there is not a real reason for peer groups. But
perhaps some generic tool for sharing common defaults would be
Hello!
For us ECMP is important as we load balance connections to remote customer
sites across different ISPs for redundancy and performance.
When doing that, please keep in mind that whenever the characteristics
(delay and throughput) of the lines are different, TCP congestion control
Hello!
Yes, it is unlikely but if that were to happen you will have
a very hard time finding the problem as the real cause would
not be visible and only on some platform/gcc version.
... or add an ASSERT.
Sure, but I am not sure if pointer references are covered fully by C.
This case is
Hello!
hmm, why bomb out when not needed?
It does not matter. It must not occur in production versions either,
it should exist only as a warning for developers during testing.
Have a nice fortnight
--
Martin `MJ' Mares m...@ucw.cz
Hello!
Pehaps this it is always safe to use memcpy in this case, but the man
page doesn't.
Neither it is allowed by the C standard.
It is also a waste of cycles as the whole op is a NOP.
Sure -- that's why we have split the copying and in-place conversion.
Hello!
That choice does exist yet unless you plan to do it?
The choice exists: either leave the current work-around, or change it to
your work-around. Neither is a proper fix.
Have a nice fortnight
--
Martin `MJ' Mares m...@ucw.cz
Hello!
No, but it is the equivalent of renaming a variable from an ideal name
to a less ideal name, not a big deal.
It's called breaking invariants. So far, all tokens were named in a uniform,
systematic way. Your patch breaks it. Hence your patch is buggy.
Do not fix a problem by introducing
Hello!
I have moved the the workaround to where it belongs,
in the grammar files. The current kludge masks potential bugs
and causes compiler warnings and is a much worse workaround than the
one I offer while we wait for you to fix the token name space.
No need to wait for me. You can
Hello!
That would only get rid of the warning, but REJECT is still
a reserved word(-Cf still fails).
This should not be a problem as we don't use -Cf, should it?
(BTW blindly detecting every occurrence of the substring REJECT in the
C code snippets smells of a bug in flex. It might very well
Hello!
Haven't you heard a word ? ECHO, REJECT and BEGIN are pre defined
actions in flex that you can use in your C code. Go read flex again.
I know that. But what does that really means from the point of view
of C syntax (as used in the C snippets contained in the C source)?
Go read the C
Hello!
This is no issue, we already require GCC.
If so, then ACK from me.
(BTW where we rely on GCC?)
Have a nice fortnight
--
Martin `MJ' Mares m...@ucw.cz http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague,
This kills:
cf-lex.c:1874: warning: 'yy_fatal_error' defined but not used
Sorry, but this is much more ugly than the warning itself.
What about declaring yy_fatal_error() with UNUSED?
Have a nice fortnight
--
Martin `MJ' Mares
Hello!
I noticed the compile warning caused by it and looked for the
reason. I didn't notice any problem but such conflicts are a bug
waiting to happen so I tried to fix it.
Again, the fix is uglier than the symptoms of the problem.
The best fix would be to prefix all tokens(say TOK_) so
Hello!
while(buf != end) got worse in ppc. gcc 4.3.4 got even more worse
than gcc 3.4.6. I think it is safe to say that gcc 4.3.4 is busted when
it comes to optimization, even on x86. Seen -O1 do better than -O2 for
x86 with gcc 3.4.3.
BTW have you tried unrolling the loops or using
Hello!
Here are a series of performance improvements on the
Internet checksum. With these changes applied I get about
20-30% better performance on x86 and PowerPC.
Even though we got off on the wrong foot I got curious
enough to do some more investigation and I leared
more about add with
Some archs(RISC like archs) can do pre increment and load
in one insn but gcc optimization often fails to take advantage
of that. Help gcc to do the right thing by using pre increment
instead of post increment.
This one is a little bit dubious, I would rather not twist the code
so much in
Hello!
This is a much simpler and efficent impl. of the IP checksum.
It is a dry port from Quagga and I have not tested it.
Are you convinced that your version is more efficient? The original version
processes 32 bits at a time, while your code does only 16 bits at a time. It
might
be worth
Hello!
Fairly, I once had the same idea for Quagga but found all those extra tests
and
additions were much slower(I benched it). Just look at the number of extra
ops one
has to do in the current code.
If you want to do it faster you have to go ASM. It would be easy to
add support for
Hello!
But it slows down the fletcher checksum as one need to test and extra
calculations because of this. Any gain by the separation is lost many times
over
in the fletcher checksum which could be as simple as(from Quagga with my
tweaks):
Again, do you have any real numbers backing this
Hello!
But you can't get rid of:
z + (z sum)
which is the real bottleneck. Perhaps this doesn't cost much
on high end CPUs but it sure does on embedded CPUs
Why should it be? It can be compiled as a sequence of add with carry
instructions, can't it?
Have
Hello!
Just tried this and it didn't with gcc 3.4.3 on PowerPC
It would be better to let gcc unroll the loop (if it is critical for
performance, it should be unrolled anyway) and use a newer version of gcc.
Some arch does not have an add with carry insn(MIPS?)
Well, first of all, we should
Hello!
So there isn't really difference in performance of both
implementations. Even on slow embedded AMD Geode CPU, it gives
~ 180 MB/s.
No difference? what does 1.2 mean? to me this means 20% which is a lot
Yes, but according to Santiago's benchmarks, your code is sometimes 20%
Hello!
Peformance matter, especially when the network grows. Is this the way
BIRD development works? Only work on stuff that currently feels important
is acceptet?
Yes, performance matters. This is why performance optimizations in BIRD
have to be justified by real numbers, not by hand-waving.
Hello!
So basically you are saying that outsiders like my self aren't welcome
because BIRD is so important to some IXPs that you don't want to
take any chanches?
Certainly not. However, it means that the criteria for accepting patches
are somewhat stricter than in many other projects.
All
On Mon, Mar 22, 2010 at 08:41:16AM +0100, Wolfgang Hennerbichler wrote:
Good Morning Ondrej Ondrej,
would it be possible to let bird6 log with the bird6 prefix to syslog
instead of bird?
Good idea. Definitely.
Wouldn't it be better to make the prefix configurable?
35 matches
Mail list logo
