Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Re-designing the config parsers (Marcin Siodelski)
2. Re: Re-designing the config parsers (Daniil Baturin)
3. kea-dhcp4 - benchmarks (memfile and mysql) (Chaigneau, Nicolas)
4. Re: Re-designing the config parsers (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 Sep 2014 15:44:16 +0200
From: Marcin Siodelski <[email protected]>
To: [email protected]
Subject: Re: Re-designing the config parsers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 12/09/14 12:44, Francis Dupont wrote:
> Tomek Mrugalski writes:
>> On 11.09.2014 18:01, Francis Dupont wrote:
>>> Marcin Siodelski writes:
>>>> I should also explain that we discussed with Tomek a use of Bison
>>>> framework (http://www.gnu.org/software/bison/) in Kea.
>>>
>>> => I heavily used bison (and other LALR(1) parsers) in the past...
>>> BTW if you want to provide a parser style config, IMHO the best
>>> available is JunOS from Juniper (far better than the Cisco config).
>> No, we don't want to change the format. It will stay as it is.
>> The plan is to refactor/redo the code that parses that input.
>
> => so you have bison and equivalent, and for hand written parsers
> top down vs bottom up.
>
So, a statetement about bottom-up vs top-down doesn't tell me much if I
can make Bison parse the elements of the configuration in a desired
order. So for example, the simplified configuration file:
----
dhcp-option-fqdn = "foo.marcin.com"
dhcp-option-fqdn has type FQDN
----
defines a value for the new option called "dhcp-option-fqdn" in the
first line and the option format in the second line.
So, I want the parser to read the format of the option (second line)
before reading the option data "foo.marcin.com" and I want to report a
parser error if the "foo.marcin.com" is not a legal fqdn.
Is this configurable?
Marcin
------------------------------
Message: 2
Date: Fri, 12 Sep 2014 21:16:28 +0700
From: Daniil Baturin <[email protected]>
To: [email protected]
Subject: Re: Re-designing the config parsers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/12/2014 08:44 PM, Marcin Siodelski wrote:
>
>
> On 12/09/14 12:44, Francis Dupont wrote:
>> Tomek Mrugalski writes:
>>> On 11.09.2014 18:01, Francis Dupont wrote:
>>>> Marcin Siodelski writes:
>>>>> I should also explain that we discussed with Tomek a use of Bison
>>>>> framework (http://www.gnu.org/software/bison/) in Kea.
>>>>
>>>> => I heavily used bison (and other LALR(1) parsers) in the past...
>>>> BTW if you want to provide a parser style config, IMHO the best
>>>> available is JunOS from Juniper (far better than the Cisco config).
>>> No, we don't want to change the format. It will stay as it is.
>>> The plan is to refactor/redo the code that parses that input.
>>
>> => so you have bison and equivalent, and for hand written parsers
>> top down vs bottom up.
>>
>
>
> So, a statetement about bottom-up vs top-down doesn't tell me much if I
> can make Bison parse the elements of the configuration in a desired
> order. So for example, the simplified configuration file:
>
> ----
> dhcp-option-fqdn = "foo.marcin.com"
> dhcp-option-fqdn has type FQDN
> ----
>
> defines a value for the new option called "dhcp-option-fqdn" in the
> first line and the option format in the second line.
>
> So, I want the parser to read the format of the option (second line)
> before reading the option data "foo.marcin.com" and I want to report a
> parser error if the "foo.marcin.com" is not a legal fqdn.
>
> Is this configurable?
>
> Marcin
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
Checking the format and determining the type of tokens is the job of a
lexer, not a parser.
Also, said grammar is not just LALR(1)-unfriendly, it's not even
context-free.
Also #2, top-down and bottom-up are not about the direction the file is
read. :)
They are about building the syntax tree from the top (picking the most
general rule, such as "config ::= expressions" and checking is a
sequence of tokens is compatible with its structure) or from the bottom
(finding token sequences that match more specific rules, such as "option
::= identifier = value" and checking which more general rule it can be a
part of).
- --
#!/usr/bin/env perl
@a=split(//, "daniil @ baturin . org" );# Daniil Baturin
@b=split(//,q/Px%!+o0Q6lh*7dp$.@8#%|y{/);while($i<24){$_.=
chr((ord(@b[$i])-ord(@a[$i])+62)%94+32);$i++};print"$_\n"#
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJUEwA8AAoJEEcm35UR4K8fyloQAOoKpVXeHQbUF/TEyX5M96vL
jxq9aWZFr26MyctPIVg945bUnAqooVhbe9f1SPwUrIkGmWXEOmpG7s/HNweJWITx
ahNqs3fRTS5L77u0qdDlqGdOPz9q+oi6QLxTaFhlOhf6YOmqqfEx+4CNuNnG75Me
IguN72wWZprCxFPAwyeR0PTgFSMx8Kw7hFr1F3MihVO5AEDacjp74HHcUNj4fNyM
LvgledcKWZfNd2rrhFJFPKG/jOl3u8zpe6fVGgwueRKlOSR4PIdzwjSGXsLh2zjq
1oJe3cR6i42baDKwRzXuzRJFM4js2GAOZsKDWn3BGTHFI8dLt9VhXLJo5QyUMYfj
IUmU6rKt5hxXWdeOGVhZO8v/k7aWh56ZeR58xABjgli8K2Ku+4srIslczZfA98yN
JZ78/gLiC+SKSGxXDXlJVJfpj/VRnOjYzT3oWFiyx4Ss5ed9que6YxwyLdotyPyh
ZAs53ldGAgJfiSd2EWxw7iWlGwQwQ3zk0UD+Lc4AYJJEcYIxH242C02MNOFIaOdV
hQwUh3lwnq8WldLSf9WEP2QdBLDH2Kn2HQNznv2Dl6JcIU9zFQk+PLZEUDB1kBUB
vpj7YaHE3rgqgaaE3Dx3TDLAPFNRiaD+aL3sHo91MlFdrOlVHPfHEf+LBwQrb3W/
OEVrxV+yfpLbXG17xsG7
=eFyl
-----END PGP SIGNATURE-----
------------------------------
Message: 3
Date: Fri, 12 Sep 2014 15:25:58 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: kea-dhcp4 - benchmarks (memfile and mysql)
Message-ID:
<ab94b0b675bdf14189cd5a861db36c8414183...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello again,
I've tried to benchmark Kea 0.9, using perfdhcp.
I'm measuring the number of DORA transactions/s the server is able to handle
without client experiencing drops (with default perfdhcp drop-time of 1 sec).
>From Kea Update #3:
"Kea now offers reasonably high performance, leases per second wise. We managed
to get over 1000 leases/sec for MySQL and 8000 leases/sec for memfile in
memory-only mode on one of our high-performance servers. (Your mileage may
vary.) >
I don't expect the same numbers, since I don't have the same server and setup
than you do, but still these are useful comparison values.
With a persistent memfile, I get about 4100 leases/sec.
This is about half your number, but still good.
As a comparison, on the same scenario dhcpd (with a single process) handles at
most 70 leases/s.
With MySQL, though, I do not manage to get anywhere your numbers.
I manage to get about 50 leases/s (which is worse than dhcpd...)
I'm using MySQL 5.6.20. I've created the schema using the script provided with
the kea 0.9 package.
I left all MySQL parameters as default.
The CPU usage is very low: about 5% for mysqld, and 3% for kea-dhcp4 (both
processes, as well as the datafiles, are on the same server)
Memory isn't an issue either.
I've noticed that Kea uses a single database handle.
Wouldn't that be a bottleneck ? (and isn't Kea server multi-threaded ?)
So my question is, how did you manage to get 1000 leases/s ? am I doing
something wrong ? do you have recommandations for the MySQL setup ?
Thanks in advance for any advice.
Regards,
Nicolas.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20140912/db4a8f15/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 12 Sep 2014 19:54:54 +0000
From: Francis Dupont <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: [email protected]
Subject: Re: Re-designing the config parsers
Message-ID: <[email protected]>
Marcin Siodelski writes:
> On 12/09/14 12:44, Francis Dupont wrote:
> > Tomek Mrugalski writes:
> >> On 11.09.2014 18:01, Francis Dupont wrote:
> >>> Marcin Siodelski writes:
> >>>> I should also explain that we discussed with Tomek a use of Bison
> >>>> framework (http://www.gnu.org/software/bison/) in Kea.
> >>>
> >>> => I heavily used bison (and other LALR(1) parsers) in the past...
> >>> BTW if you want to provide a parser style config, IMHO the best
> >>> available is JunOS from Juniper (far better than the Cisco config).
> >> No, we don't want to change the format. It will stay as it is.
> >> The plan is to refactor/redo the code that parses that input.
> >
> > => so you have bison and equivalent, and for hand written parsers
> > top down vs bottom up.
> >
>
>
> So, a statetement about bottom-up vs top-down
=> bison is LALR(1) so bottom-up (BTW my statement about bottom-up vs
top-down was for hand written parsers, so not for bison & co where
the used mechanism is fixed, at the opposite to write a grammar is
far lighter than to write a full parser).
> doesn't tell me much if I can make Bison parse the elements of the
> configuration in a desired order.
=> all parsers I know are left to right. IMHO what do you want is not
a parser (aka syntax analyser).
> So for example, the simplified configuration file:
>
> ----
> dhcp-option-fqdn = "foo.marcin.com"
> dhcp-option-fqdn has type FQDN
> ----
>
> defines a value for the new option called "dhcp-option-fqdn" in the
> first line and the option format in the second line.
=> the line as a basic construct is not the best...
> So, I want the parser to read the format of the option (second line)
> before reading the option data "foo.marcin.com" and I want to report a
> parser error if the "foo.marcin.com" is not a legal fqdn.
=> first I recommend against context sensistive ideas, second it is
a typing problem.
> Is this configurable?
=> of course it is not.
Regards
Francis Dupont <fdupont@isc.
PS: you have an I/O system which gives the input, a lexical analyser
(aka scanner or lexer) which gives individual tokens, a syntax
analyser (aka parser) which builds a tree representing the input. Next
you have some passes on the tree, the most common and usually at the
beginning is the typing.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 6, Issue 9
*************************************
