Displaying 3 results from an estimated 3 matches for "mergeable_packet_buffer_ctx".
2013 Dec 27
4
[PATCH net-next 3/3] net: auto-tune mergeable rx buffer size for improved performance
On 12/27/2013 04:06 AM, Michael Dalton wrote:
> On Mon, Dec 23, 2013 at 4:51 AM, Michael S. Tsirkin <mst at redhat.com> wrote:
>> OK so a high level benchmark shows it's worth it,
>> but how well does the logic work?
>> I think we should make the buffer size accessible in sysfs
>> or debugfs, and look at it, otherwise we don't really know.
>>
>
2013 Dec 27
4
[PATCH net-next 3/3] net: auto-tune mergeable rx buffer size for improved performance
On 12/27/2013 04:06 AM, Michael Dalton wrote:
> On Mon, Dec 23, 2013 at 4:51 AM, Michael S. Tsirkin <mst at redhat.com> wrote:
>> OK so a high level benchmark shows it's worth it,
>> but how well does the logic work?
>> I think we should make the buffer size accessible in sysfs
>> or debugfs, and look at it, otherwise we don't really know.
>>
>
2013 Dec 27
0
[PATCH net-next 3/3] net: auto-tune mergeable rx buffer size for improved performance
...trying that out.
On Thu, Dec 26, 2013 at 7:04 PM, Jason Wang <jasowang at redhat.com> wrote:
> We can make this more accurate by using extra data structure to track
> the real buf size and using it as token.
I agree -- we can do precise buffer total len tracking. Something like
struct mergeable_packet_buffer_ctx {
void *buf;
unsigned int total_len;
};
Each receive queue could have a pointer to an array of N buffer contexts,
where N is queue size (kzalloc'd in init_vqs or similar). That would
allow us to allocate all of our buffer context data at startup.
Would this be preferred to the current a...