Hi!
On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
J> > Comparing stable/10 and head, I see two changes that could
J> > affect that:
J> >
J> > - callout_async_drain
J> > - switch to READ lock for inp info in tcp timers
J> >
J> > That's why you are in To, Julien and Hans :)
J>
Hi,
On 6/20/16 9:39 AM, Gleb Smirnoff wrote:
> On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
> J> > Comparing stable/10 and head, I see two changes that could
> J> > affect that:
> J> >
> J> > - callout_async_drain
> J> > - switch to READ lock for inp info in tcp timers
> J> >
On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote:
J> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
J> > J> > Comparing stable/10 and head, I see two changes that could
J> > J> > affect that:
J> > J> >
J> > J> > - callout_async_drain
J> > J> > - switch to READ lock
On 06/20/16 11:58, Gleb Smirnoff wrote:
The fix I am working on now is doing exactly that. callout_reset must
return 0 if the callout is currently running.
What are the old paths impacted?
Hi,
I'll dig into the matter aswell and give some comments. Thanks for the
analysis, Gleb.
FYI: This
On Mon, Jun 20, 2016 at 12:14:18PM +0200, Hans Petter Selasky wrote:
H> On 06/20/16 11:58, Gleb Smirnoff wrote:
H> > The fix I am working on now is doing exactly that. callout_reset must
H> > return 0 if the callout is currently running.
H> >
H> > What are the old paths impacted?
H>
H> Hi,
H>
H>
On 06/20/16 11:58, Gleb Smirnoff wrote:
J> callout_stop() should return 0 when the callout is currently being
J> serviced and indeed unstoppable
J>
https://reviews.freebsd.org/differential/changeset/?ref=62513&whitespace=ignore-most
What are the old paths impacted?
Hi Gleb,
Digging throu
On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote:
>
> Hi,
>
> On 6/20/16 9:39 AM, Gleb Smirnoff wrote:
> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
> > J> > Comparing stable/10 and head, I see two changes that could
> > J> > affect that:
> > J> >
> > J> > -
On 06/20/16 12:30, Gleb Smirnoff wrote:
Exactly! I am convinced that all callouts should be locked, and non-locked
one should simply go away, as well as async drain.
I agree about that that, except you still need the async drain, because
it will prevent freeing the lock protecting the callout,
On 06/20/16 12:30, Gleb Smirnoff wrote:
What does prevent us from converting TCP timeouts to locked? To my
understanding it is the lock order of taking pcbinfo after pcb lock.
I started this work:
https://reviews.freebsd.org/D1563
--HPS
___
freebsd-
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210379
--- Comment #7 from Mark Johnston ---
(In reply to Andrey V. Elsukov from comment #6)
Thanks.
I think this is a regression from r292978. Before that change, entries created
by nd6_cache_lladdr() without a specified lladdr would have report
There's implications for RSS with how the callout system currently works.
If you don't know the RSS bucket ID of a connection in advance, you'll
create callouts on the wrong CPUs and then they're not migrated.
The initial work here did convert things over, but didn't place the
callouts in the rig
Hi:sir
Nice day today
This is Vic Li form TianJin k-source Co,.Ltd
We have a pure color Are of good quality Impurities in the caustic soda pearls
and caustic soda flake Compared to other products of our product color more
pure price more appropriate
Look forward to cooperation with you
Rgds
Hi,
On 6/20/16 12:30 PM, Gleb Smirnoff wrote:
> On Mon, Jun 20, 2016 at 12:14:18PM +0200, Hans Petter Selasky wrote:
> H> On 06/20/16 11:58, Gleb Smirnoff wrote:
> H> > The fix I am working on now is doing exactly that. callout_reset must
> H> > return 0 if the callout is currently running.
> H>
Hi,
On 6/20/16 11:58 AM, Gleb Smirnoff wrote:
> On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote:
> J> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
> J> > J> > Comparing stable/10 and head, I see two changes that could
> J> > J> > affect that:
> J> > J> >
> J>
Hi,
I'm not sure if it's just me being tired, but I'm facing the following
problem on 10.3-RELEASE when moving an IPv4 alias from one host to
the other. This is an example of what I'm seeing:
Configuration:
Box 1:
ifconfig_bge0_name="uplink"
ifconfig_uplink="inet 10.1.1.253/24 description 'uplin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210417
Mark Linimon changed:
What|Removed |Added
Keywords||IntelNetworking
Assignee|
Michael Gmelin [2016-06-21 02:27 +0200] :
> I'm not sure if it's just me being tired, but I'm facing the following
> problem on 10.3-RELEASE when moving an IPv4 alias from one host to
> the other. This is an example of what I'm seeing:
[...]
> It's still in the arp table as a non-permanent entry,
17 matches
Mail list logo
