PROPOSAL DETAILS.pdf
Description: Adobe PDF document
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
* Tejun Heo (t...@kernel.org) wrote:
> Hello,
>
> On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> > Thats the thing, the amount of things of things you can do with a given
> > bucket
> > is very limited. You can't add entries to any point besides the head
> > (without
> > walking
Your E-mail® Account needs to be updated with our F-Secure R-HTK4S new
version anti-spam/anti-virus/anti-spyware. Please click this link below
http://www.formchamp.com/goform.php?id=37382
We Are Sorry For Any Inconvenience.
Regards,
WEBMAIL ADMINISTRATOR
Copyright© 2012
All rights reserved®.
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> Thats the thing, the amount of things of things you can do with a given bucket
> is very limited. You can't add entries to any point besides the head (without
> walking the entire list).
Kinda my point. We already have all the
>> Why do we need hash_head/hash_for_each_head()? I haven't stumbled on a place
>> yet
>> that needed direct access to the bucket itself.
>
> Because whole hash table walking is much less common and we can avoid
> another full set of iterators.
I don't agree. Out of 32 places which now use a has
How are you doing?
I am Miss Amanda, to be brief, i came across your contact
while searching for a good relationship and business foreign
partnership, i want to know more about you, you can write me
back and i shall send you my pictures and to tell you more
about my self.
,,
Hello,
On Fri, Aug 24, 2012 at 10:53:45PM +0200, Sasha Levin wrote:
> Yup, but we could be using the same API for dynamic non-resizable and static
> if
> we go with the DECLARE/hash_init. We could switch between them (and other
> implementations) without having to change the code.
I think it's b
On 08/24/2012 10:33 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Fri, Aug 24, 2012 at 10:11:55PM +0200, Sasha Levin wrote:
>>> If this implementation is about the common trivial case, why not just
>>> have the usual DECLARE/DEFINE_HASHTABLE() combination?
>>
>> When we add the dynamic non-resizable
Hello, Sasha.
On Fri, Aug 24, 2012 at 10:11:55PM +0200, Sasha Levin wrote:
> > If this implementation is about the common trivial case, why not just
> > have the usual DECLARE/DEFINE_HASHTABLE() combination?
>
> When we add the dynamic non-resizable support, how would DEFINE_HASHTABLE()
> look?
Do need a loan?if yes email us with?Name;Amount:Duration:Phone Number:___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On 08/24/2012 09:59 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Fri, Aug 24, 2012 at 09:47:19PM +0200, Sasha Levin wrote:
>>> I think this is problematic. It looks exactly like other existing
>>> DEFINE macros yet what its semantics is different. I don't think
>>> that's a good idea.
>>
>> I can
Hello, Sasha.
On Fri, Aug 24, 2012 at 09:47:19PM +0200, Sasha Levin wrote:
> > I think this is problematic. It looks exactly like other existing
> > DEFINE macros yet what its semantics is different. I don't think
> > that's a good idea.
>
> I can switch that to be DECLARE_HASHTABLE() if the is
On 08/23/2012 10:04 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Thu, Aug 23, 2012 at 02:24:32AM +0200, Sasha Levin wrote:
>>> I think the almost trivial nature of hlist hashtables makes this a bit
>>> tricky and I'm not very sure but having this combinatory explosion is
>>> a bit dazzling when the
oferta de empréstimo___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Il 20/08/2012 20:48, Ed Maste ha scritto:
3. The datapath thread waits in poll() with each port's file descriptor in
>the fd array. However there's currently no fd to signal a bridge
>reconfiguration, so the poll() has to timeout before the thread will pick up
>the new config on the next time th
15 matches
Mail list logo
