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 a
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 differe
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!
> As i understand, now when i mistakenly delete a route from kernel table,
> bird restore it on the next table scan. How will this works without table
> scan?
The short answer is "Don't do that" :-)
BIRD is not a tool for preventing you from shooting yourself in the foot.
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 disru
Hello!
> > It is very costy and one (developer) possibility is to add
> > additional thread which does kernel interaction.
>
> I think that a separate thread can solve this nuisance.
... at the cost of introducing lots of extra complexity.
I think that deferring kernel route updates (and mayb
Hello!
> What is a point if both Linux and BSD also has such limit?
Well, not all the world is Linux or BSD. Since beginning, most parts of BIRD
avoid any such system dependencies and I still think it's a good idea.
Also, it's generally a good practice to avoid arbitrary limits on size
of anythi
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
Hello!
> diff --git a/proto/bgp/bgp.h b/proto/bgp/bgp.h
> index 0c50583..76f0400 100644
> --- a/proto/bgp/bgp.h
> +++ b/proto/bgp/bgp.h
> @@ -50,6 +50,7 @@ struct bgp_config {
>unsigned error_delay_time_min; /* Time to wait after an error is
> detected */
>unsigned error_delay_time_ma
Hello!
> But it seems that your problem is not exactly with signedness, but with
> overflow (instead of saturation). Overflow works also the same for
> signed and unsigned ones.
>
> I thought about this some time ago and probably the best solution would
> be to switch BIRD completely to unsigned
Hello!
> >Why is it called MPLS, when we call all other configuration switches
> >CONFIG_something?
> I thought CONFIG_XXX relates to protocol support and general features is
> defined like IPV6, without any prefix.
IPV6 is a rather special case, in the retrospect I think it should have
got the C
Ahoj!
> commit ee3256fe1cb3e429de22e7c50a0826aaa4dc7a73
> Author: Ondrej Zajicek
> 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
nit-picking com
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
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 woul
Hi!
> Oh, come on. IS-IS is much better than OSPF.
I am not sure if anything that uses ASN.1 can be considered better ;-)
At least in my eyes, ASN.1 is an equivalent of TeX badness -1,
i.e., it makes an arbitrary protocol infinitely ugly.
> It's protocol can be
> extended using new TLV value
Hi!
> And your implementation of IS-IS will require running OSI protocol stack
> and CLNS? :-)
If somebody ever implements IS-IS in BIRD.
IMHO it's much better to let IS-IS enjoy the fate of dinosaurs, being
one of them :-)
Have a nice fortnight
--
Martin `MJ' M
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
algori
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!
> 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 http://mj.ucw.
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!
> 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 st
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 we
Hello!
> `flex' scans your rule actions to determine whether you use the
> `REJECT' or `yymore()' features. The `REJECT' and `yymore' options are
> available to override its decision as to whether you use the options,
> either by setting them (e.g., `%option reject)' to indicate the feature
> is
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 su
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 introducin
Hello!
> Right, neither is an ideal fix but at least mine is "correct" and doesn't
> cause REJECT to be defined inside flex, causing warnings.
>
> I don't understand your reasoning, you rather keep the buggy REJECT
> instead of renaming the bison token REJECT to Reject because it
> doesn't look a
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 http://mj.ucw.
Hello!
> > Again, the fix is uglier than the symptoms of the problem.
>
> Picky, you rather stare at that warning and the ugly
> #undef REJECT plus some potential bug yet to be found?
No, I would rather like to commit a proper fix, not an ugly hack,
which tries to fix something which has never b
Hello!
> > Sorry, but this is much more ugly than the warning itself.
>
> No, it isn't. You don't have look at that every compile.
So disable the warning.
Have a nice fortnight
--
Martin `MJ' Mares http://mj.ucw.cz/
Faculty of Math an
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
> 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 http
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 http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep.,
Hello!
> Although i don't like the patch, i can't find a better way to fix this
> so i will probably merge that.
>
> MJ, do you have some comment on this [*]?
>
> [*] http://marc.info/?l=bird-users&m=127200916013140&w=2
I am getting Internal Server Error at this URL now. Do I guess correctly th
Hello!
> > Huh, what should do endianity have in common with the choice of
> > pre-/postincrement?
>
> Because most archs that can deal with preinc. are big endian, the
> for loop is important too. Decrement and test for zero is basically free.
If GCC generates obviously suboptimal code on some
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 __att
> 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!
> 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 "ad
Hello!
> It seems to me that you are so afraid to break something for your precious
> IXPs that you rather drop user contributions than integrate them unless
> the changes has been proven correct. I, as a developer, has to do all the
> work, testing and "prove" that the change is "good". My view
Hello!
> How did you come to the conclusion the the current code was better than
> the previous version? Seems like "hand waving" to me.
Did I claim anywhere that the old code is better? I only pointed out
the lack of arguments about the new code being better, which is a reason
to stay with the
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
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-wavin
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 sometim
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!
> 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?
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 t
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 f
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
> 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?
Hello!
> It is not possible. I have this feature in TODO list, but it is pretty
> big change. OTOH, for just the route server case (just BGP without
> kernel routing table sync) that might be an easy.
It might be also possible to drop root UID, but retain a subset of root's
capabilities, e.g., bi
52 matches
Mail list logo
