On 7/14/11 8:44 AM, Gleb Smirnoff wrote:
Hi!
This problem is definitely known and is as old as network stack
is parallel. Those, who know the problem may skip to next paragraph.
Short description is the following: every mbuf that is allocated in
an interface receive procedure has a field w
On Tue, Jul 26, 2011 at 10:09:09AM +0100, Robert N. M. Watson wrote:
>
> On 25 Jul 2011, at 12:00, Daan Vreeken wrote:
>
> > Couldn't the dangling pointer problem be solved by adding a 'generation'
> > field
> > to the mbuf structure?
> > The 'generation' could be a system-wide number that gets
On 25 Jul 2011, at 12:00, Daan Vreeken wrote:
> Couldn't the dangling pointer problem be solved by adding a 'generation'
> field
> to the mbuf structure?
> The 'generation' could be a system-wide number that gets incremented whenever
> an interface is removed. The mbuf* functions could keep a
Hi Robert,
On Sunday 24 July 2011 10:43:59 Robert N. M. Watson wrote:
> On 24 Jul 2011, at 04:51, Ryan Stone wrote:
> > I ran headlong into this issue today when trying to test some network
> > stack changes. It's depressingly easy to crash HEAD by periodically
> > destroying vlan interfaces whil
On Sun, Jul 24, 2011 at 09:43:59AM +0100, Robert N. M. Watson wrote:
R> Instead, I think we should go for a more radical notion, which is a bit
harder to implement in our stack: the network stack needs a race-free way to
"drain" all mbufs referring to a particular ifnet, which does not cause
exi
On 24 Jul 2011, at 04:51, Ryan Stone wrote:
> I ran headlong into this issue today when trying to test some network
> stack changes. It's depressingly easy to crash HEAD by periodically
> destroying vlan interfaces while you are sending traffic over those
> interfaces -- I get a panic within min
I ran headlong into this issue today when trying to test some network
stack changes. It's depressingly easy to crash HEAD by periodically
destroying vlan interfaces while you are sending traffic over those
interfaces -- I get a panic within minutes.
> http://people.freebsd.org/~glebius/patches/if
On Sun, Jul 17, 2011 at 7:59 AM, Vadim Goncharov wrote:
> Ways to improve are to be found from this starting point. However,
> are that +2 atomic ops per packet really so expensive? How many of
> atomic ops are already on that path? Any measures?
On high-performance multiqueue NICs, those two ato
Hi Gleb Smirnoff!
On Thu, 14 Jul 2011 19:44:57 +0400; Gleb Smirnoff wrote about 'm_pkthdr.rcvif
dangling pointer problem':
> 1) Every m_pkthdr.rcvif should if_ref() the interface. Releasing
> references can be done in the mbuf allocator: mb_dtor_mbuf(),
> mb_dtor_pack
On Thu, Jul 14, 2011 at 05:27:01PM -0700, John-Mark Gurney wrote:
J> Gleb Smirnoff wrote this message on Thu, Jul 14, 2011 at 19:44 +0400:
J> > 2) kib@ suggested to allocate ifnets from a UMA_ZONE_NOFREE zone.
J> > I've made a compilable & working patch:
J> >
J> > http://people.freebsd.org/~gleb
Gleb Smirnoff wrote this message on Thu, Jul 14, 2011 at 19:44 +0400:
> 2) kib@ suggested to allocate ifnets from a UMA_ZONE_NOFREE zone.
> I've made a compilable & working patch:
>
> http://people.freebsd.org/~glebius/patches/ifnet.no_free
>
> But on second though I find this a bad idea, this
On Thu, Jul 14, 2011 at 07:44:57PM +0400, Gleb Smirnoff wrote:
> Hi!
>
> This problem is definitely known and is as old as network stack
> is parallel. Those, who know the problem may skip to next paragraph.
> Short description is the following: every mbuf that is allocated in
> an interface r
Hi!
This problem is definitely known and is as old as network stack
is parallel. Those, who know the problem may skip to next paragraph.
Short description is the following: every mbuf that is allocated in
an interface receive procedure has a field where a pointer to the
corresponding struct if
13 matches
Mail list logo
