Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1280069 > unrolled thread

Re: [PATCH 00/13] mvneta Buffer Management and enhancements

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 00/13] mvneta Buffer Management and enhancements David Miller <davem@redhat.com> - 2015-11-30 17:30 +0100
    Re: [PATCH 00/13] mvneta Buffer Management and enhancements Marcin Wojtas <mw@semihalf.com> - 2015-12-02 09:30 +0100
      Re: [PATCH 00/13] mvneta Buffer Management and enhancements Florian Fainelli <f.fainelli@gmail.com> - 2015-12-04 21:20 +0100
        Re: [PATCH 00/13] mvneta Buffer Management and enhancements Marcin Wojtas <mw@semihalf.com> - 2015-12-08 12:00 +0100
          Re: [PATCH 00/13] mvneta Buffer Management and enhancements David Miller <davem@davemloft.net> - 2015-12-08 18:00 +0100

#1280069 — Re: [PATCH 00/13] mvneta Buffer Management and enhancements

From: Marcin Wojtas <mw@semihalf.com>
Date: Mon, 30 Nov 2015 15:13:22 +0100

> What kind of abstraction and helpers do you mean? Some kind of API
> (e.g. bm_alloc_buffer, bm_initialize_ring bm_put_buffer,
> bm_get_buffer), which would be used by platform drivers (and specific
> aplications if one wants to develop on top of the kernel)?
> 
> In general, what is your top-view of such solution and its cooperation
> with the drivers?

The tricky parts involved have to do with allocating pages for the
buffer pools and minimizing the number of atomic refcounting
operations on those pages for for the puts and gets, particularly
around buffer replenish runs.

For example, if you're allocating a page for a buffer pool the device
will chop into N (for any N < PAGE_SIZE) byte pieces, you can
eliminate many atomic operations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1281518

Hi Florian,

Can you please describe in more details, what would you expect from
such special abstraction layer regarding buffer managers? I'd like to
understand more of your expectations and evaluate possible work.

Best regards,
Marcin

2015-11-30 17:25 GMT+01:00 David Miller <davem@redhat.com>:
> From: Marcin Wojtas <mw@semihalf.com>
> Date: Mon, 30 Nov 2015 15:13:22 +0100
>
>> What kind of abstraction and helpers do you mean? Some kind of API
>> (e.g. bm_alloc_buffer, bm_initialize_ring bm_put_buffer,
>> bm_get_buffer), which would be used by platform drivers (and specific
>> aplications if one wants to develop on top of the kernel)?
>>
>> In general, what is your top-view of such solution and its cooperation
>> with the drivers?
>
> The tricky parts involved have to do with allocating pages for the
> buffer pools and minimizing the number of atomic refcounting
> operations on those pages for for the puts and gets, particularly
> around buffer replenish runs.
>
> For example, if you're allocating a page for a buffer pool the device
> will chop into N (for any N < PAGE_SIZE) byte pieces, you can
> eliminate many atomic operations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284195

(no top posting please)

On 02/12/15 00:26, Marcin Wojtas wrote:
> Hi Florian,
> 
> Can you please describe in more details, what would you expect from
> such special abstraction layer regarding buffer managers? I'd like to
> understand more of your expectations and evaluate possible work.

Well, something along these lines:

- have the ability to register a particular pool (location + number of
buffers) in a way that is relatively device agnostic (initialization
would of course be device specific)

- provide a set of buffer management APIs like those you proposed below,
and have some generic code that leverages what
drivers/net/ethernet/sun/niu.c does for instance

- introduce a netdev_alloc_skb_from_pool() or something like that which
would limit the amount of code to change in your network driver to
benefit from that feature so based

I am sure David would be able to suggest more detailed API.

> 
> Best regards,
> Marcin
> 
> 2015-11-30 17:25 GMT+01:00 David Miller <davem@redhat.com>:
>> From: Marcin Wojtas <mw@semihalf.com>
>> Date: Mon, 30 Nov 2015 15:13:22 +0100
>>
>>> What kind of abstraction and helpers do you mean? Some kind of API
>>> (e.g. bm_alloc_buffer, bm_initialize_ring bm_put_buffer,
>>> bm_get_buffer), which would be used by platform drivers (and specific
>>> aplications if one wants to develop on top of the kernel)?
>>>
>>> In general, what is your top-view of such solution and its cooperation
>>> with the drivers?
>>
>> The tricky parts involved have to do with allocating pages for the
>> buffer pools and minimizing the number of atomic refcounting
>> operations on those pages for for the puts and gets, particularly
>> around buffer replenish runs.
>>
>> For example, if you're allocating a page for a buffer pool the device
>> will chop into N (for any N < PAGE_SIZE) byte pieces, you can
>> eliminate many atomic operations.


-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1286388

Hi David,

2015-12-04 21:15 GMT+01:00 Florian Fainelli <f.fainelli@gmail.com>:
> (no top posting please)
>
> On 02/12/15 00:26, Marcin Wojtas wrote:
>> Hi Florian,
>>
>> Can you please describe in more details, what would you expect from
>> such special abstraction layer regarding buffer managers? I'd like to
>> understand more of your expectations and evaluate possible work.
>
> Well, something along these lines:
>
> - have the ability to register a particular pool (location + number of
> buffers) in a way that is relatively device agnostic (initialization
> would of course be device specific)
>
> - provide a set of buffer management APIs like those you proposed below,
> and have some generic code that leverages what
> drivers/net/ethernet/sun/niu.c does for instance
>
> - introduce a netdev_alloc_skb_from_pool() or something like that which
> would limit the amount of code to change in your network driver to
> benefit from that feature so based
>
> I am sure David would be able to suggest more detailed API.
>

As we're getting closer to what a generic BM part, could you please
share your thoughts on the possible API?


>>>
>>>> What kind of abstraction and helpers do you mean? Some kind of API
>>>> (e.g. bm_alloc_buffer, bm_initialize_ring bm_put_buffer,
>>>> bm_get_buffer), which would be used by platform drivers (and specific
>>>> aplications if one wants to develop on top of the kernel)?
>>>>
>>>> In general, what is your top-view of such solution and its cooperation
>>>> with the drivers?
>>>
>>> The tricky parts involved have to do with allocating pages for the
>>> buffer pools and minimizing the number of atomic refcounting
>>> operations on those pages for for the puts and gets, particularly
>>> around buffer replenish runs.
>>>
>>> For example, if you're allocating a page for a buffer pool the device
>>> will chop into N (for any N < PAGE_SIZE) byte pieces, you can
>>> eliminate many atomic operations.
>

Do you think you can point to anything similar that could be a sort of
reference for such solution?

Best regards,
Marcin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1286693

From: Marcin Wojtas <mw@semihalf.com>
Date: Tue, 8 Dec 2015 11:56:28 +0100

> Do you think you can point to anything similar that could be a sort
> of reference for such solution?

I don't have much time to explain because I'm constantly backlogged doing
patch review, but mostly it has to do with page management and avoiding
atomic decrement/increment of page counts wherever possible while feeding
blocks to the chip and receiving packets.

Please don't ask me for any more details as I'm really backlogged doing
patch review at the moment.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web