[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cf95797a1a964e2ea6c525d7070f6f94@AMSPEX02CL03.citrite.net>
Date: Mon, 9 May 2016 08:56:44 +0000
From: Paul Durrant <Paul.Durrant@...rix.com>
To: David Miller <davem@...emloft.net>
CC: "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Wei Liu <wei.liu2@...rix.com>
Subject: RE: [PATCH net-next 2/4] xen-netback: add control protocol
implementation
> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: 07 May 2016 20:09
> To: Paul Durrant
> Cc: xen-devel@...ts.xenproject.org; netdev@...r.kernel.org; Wei Liu
> Subject: Re: [PATCH net-next 2/4] xen-netback: add control protocol
> implementation
>
> From: Paul Durrant <paul.durrant@...rix.com>
> Date: Thu, 5 May 2016 12:19:28 +0100
>
> > +struct xenvif_hash_cache {
> > + rwlock_t lock;
>
> You really don't want to lock on every SKB hash computation like
> this, turn this into a spin lock for locking the write side and
> use RCU locking for lookup and usage.
>
Yes, that would be better. Will do.
Cheers,
Paul
> THanks.
Powered by blists - more mailing lists