On Tue, 24 Apr 2018 22:05:10 +0200
Thomas Monjalon wrote:
> 24/04/2018 19:25, Burakov, Anatoly:
> > On 24-Apr-18 5:32 PM, Stephen Hemminger wrote:
> > > On Tue, 24 Apr 2018 16:54:21 +0100
> > > Anatoly Burakov wrote:
> > >
> > >> One of the ways to work around this was using OFD locks,
> >
24/04/2018 19:25, Burakov, Anatoly:
> On 24-Apr-18 5:32 PM, Stephen Hemminger wrote:
> > On Tue, 24 Apr 2018 16:54:21 +0100
> > Anatoly Burakov wrote:
> >
> >> One of the ways to work around this was using OFD locks,
> >> but they are only supported on kernels 3.15+,
> >
> > Maybe time to move t
On 24-Apr-18 5:32 PM, Stephen Hemminger wrote:
On Tue, 24 Apr 2018 16:54:21 +0100
Anatoly Burakov wrote:
One of the ways to work around this was using OFD locks,
but they are only supported on kernels 3.15+,
Maybe time to move to next LTS kernel (3.16)?
I'm all for it, but it's not my cal
On Tue, 24 Apr 2018 16:54:21 +0100
Anatoly Burakov wrote:
> One of the ways to work around this was using OFD locks,
> but they are only supported on kernels 3.15+,
Maybe time to move to next LTS kernel (3.16)?
This patchset replaces the fcntl()-based locking used in
the original DPDK memory hotplug patchset, to an flock()-
and lockfile-based implementation, due to numerous (well,
one, really) problems with how fcntl() locks work.
Long story short, fcntl() locks will be dropped if any
fd referring to loc
5 matches
Mail list logo