[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Oct 2014 18:10:24 -0700
From: Raghuram Kothakota <Raghuram.Kothakota@...cle.com>
To: Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/2] sunvnet: Packet processing in non-interrupt context.
I would like to share my experience, on sparc we need more parallelism to
get the high performance that's just the nature of CMT processors(at least today).
Lock less Tx and Rx implementation is very nice, but requires to the code path to
single threaded to achieve it. This may limit the performance to the single thread
performance, that may be not very high for standard MTU packets. The large MTU packets
like 64K MTU may have some advantage due to less processing both in the stack
and the driver, but still single thread would limit the max performance. I would suggest
explore both lock less and high parallelism methods to see which one gives the
best performance.
-Raghuram
On Oct 6, 2014, at 12:31 PM, Sowmini Varadhan <sowmini.varadhan@...cle.com> wrote:
> On (10/06/14 15:25), David Miller wrote:
>>
>>> But we still need to hold the vio lock around the ldc_write
>>> (and also around dring write) in vnet_start_xmit, right?
>>
>> You might be able to avoid it, you're fully serialized by the TX queue
>> lock.
>
> yes, I was just noticing that. The only place where I believe I need
> to hold the vio spin-lock is to sync with the dr->cons checks
> (the "should I send a start_cons LDC message?" check in vnet_start_xmit()
> vs the vnet_ack() updates).
>
> But isn't it better in general to declare NETIF_F_LLTX and have finer lock
> granularity in the driver?
>
> --Sowmini
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists