From: Patrick McHardy <kaber@trash.net>
To: Thomas Jacob <jacob@internet24.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] Speed up verdict to chain_head mapping by using binary search
Date: Wed, 02 Jul 2008 18:00:12 +0200 [thread overview]
Message-ID: <486BA60C.6060708@trash.net> (raw)
In-Reply-To: <1215014004.26474.45.camel@enterprise.ims-firmen.de>
Thomas Jacob wrote:
> On Wed, 2008-07-02 at 17:28 +0200, Patrick McHardy wrote:
>> I can't spot any bugs, so I'm going to apply it so we can get
>> some testing. Some minor coding style issues before I'll apply
>> it though:
>>
>> Thomas Jacob wrote:
>>> diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
>>> index d0f51b4..e0c44c3 100644
>>> --- a/libiptc/libiptc.c
>>> +++ b/libiptc/libiptc.c
>>> @@ -126,6 +126,26 @@ struct chain_head
>>> unsigned int foot_offset; /* offset in rule blob */
>>> };
>>>
>>> +/* Max. number of chain_head per offsets chunk */
>>> +#define OFFSETS_CHUNK_SIZE (1024)
>>> +
>>> +struct offsets_create_chunk
>> What does "create" stand for?
>
> Well, originally I wanted to copy those chunks into an array,
> thus the create tag, so I'll just rename it to offsets_chunk,
> shall I?
Yes, that sounds better.
>
>>> +{
>>> + struct list_head list;
>>> +
>>> + unsigned int head_offset; /* of first entry */
>>> + unsigned int foot_offset; /* of last entry */
>> first_offset/last_offset perhaps?
>
> Those are the names used inside chain_head.... admittedly for the length
> of a whole change, but I could change that, no problem
That was just a suggestion triggered by the comments.
>>> +#define binary_array_range_search(value, array, left, right, size, low, high, mid, result) \
>>> + low = 0; \
>>> + high = size; \
>>> + result = -1; \
>>> + while(low<=high) \
>>> + { \
>>> + mid = (low + high) / 2; \
>>> + if ((array)[mid]->left > value) \
>>> + high = mid - 1; \
>>> + else if ((array)[mid]->right < value) \
>>> + low = mid + 1; \
>>> + else { \
>>> + if ((array)[mid]->left <= value && value <= (array)[mid]->right) \
>>> + result = mid; \
>>> + break; \
>>> + } \
>>> + }
>> Any chance to make this a bit prettier? Does it need to be a macro?
>
> No, I just didn't want to write the same code twice.... that's all,
> what do you suggest, doing that (writing the same code twice)?
No, a macro is better than duplicating it. I was just wondering
whether a function would also do.
next prev parent reply other threads:[~2008-07-02 16:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-02 11:18 [PATCH] Speed up verdict to chain_head mapping by using binary search Thomas Jacob
2008-07-02 11:18 ` [PATCH] Spelling Thomas Jacob
2008-07-02 15:28 ` [PATCH] Speed up verdict to chain_head mapping by using binary search Patrick McHardy
2008-07-02 15:53 ` Thomas Jacob
2008-07-02 16:00 ` Patrick McHardy [this message]
2008-07-02 16:07 ` Thomas Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=486BA60C.6060708@trash.net \
--to=kaber@trash.net \
--cc=jacob@internet24.de \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.