On 3/20/2019 8:21 AM, Martin K. Petersen wrote:
James,
So there are a couple of other instances you can fix at your leisure:
they're not causing immediate linux-next problems because the body of
they're only apparently used within one file so the body is available,
but if the use expands we'll
James,
> So there are a couple of other instances you can fix at your leisure:
> they're not causing immediate linux-next problems because the body of
> they're only apparently used within one file so the body is available,
> but if the use expands we'll get the same problem:
>
> lpfc_sli4.h:inl
On Tue, 2019-03-19 at 20:35 -0700, James Smart wrote:
> > On Mar 19, 2019, at 6:02 PM, James Bottomley > nPartnership.com> wrote:
> >
> > On Tue, 2019-03-12 at 16:30 -0700, James Smart wrote:
> > > Currently the driver maintains a sideband structure which has a
> > > pointer for each queue elemen
> On Mar 19, 2019, at 6:02 PM, James Bottomley
> wrote:
>
> On Tue, 2019-03-12 at 16:30 -0700, James Smart wrote:
>> Currently the driver maintains a sideband structure which has a
>> pointer for each queue element. However, at 8bytes a pointer, and up
>> to 4k elements per queue, and 100's o
On Tue, 2019-03-12 at 16:30 -0700, James Smart wrote:
> Currently the driver maintains a sideband structure which has a
> pointer for each queue element. However, at 8bytes a pointer, and up
> to 4k elements per queue, and 100's of queues, this can take up a lot
> of memory.
>
> Convert the driver
Currently the driver maintains a sideband structure which has a pointer
for each queue element. However, at 8bytes a pointer, and up to 4k
elements per queue, and 100's of queues, this can take up a lot of memory.
Convert the driver to using an access routine that calculates the
element address ba
6 matches
Mail list logo
