On 14/01/2013 07:42, Bryan Venteicher wrote:
> Any testing or performance data is welcome. For bulk TCP transfers, if_vic
> will tend to be faster than em (~1/2 a magnitude) due to TSO, but I don't
> think that warrants merging into HEAD yet.
Considering that from your description the current sit
Hi,
I have to submit some patches for Emulex's "oce" driver. Could you please
let me know if http://www.freebsd.org/send-pr.html is the correct way of
submitting them?
/Venkat
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis
On Fri, 2013-01-18 at 18:10 +0530, Venkat Duvvuru wrote:
> Hi,
> I have to submit some patches for Emulex's "oce" driver. Could you please
> let me know if http://www.freebsd.org/send-pr.html is the correct way of
> submitting them?
>
> /Venkat
Yes please. That would be the first place so that
--- On Thu, 1/17/13, Adrian Chadd wrote:
> From: Adrian Chadd
> Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx()
> To: "Barney Cordoba"
> Cc: "Luigi Rizzo" , freebsd-net@freebsd.org
> Date: Thursday, January 17, 2013, 11:48 AM
> There's also the subtle race
> condition in TX
--- On Thu, 1/17/13, Adrian Chadd wrote:
> From: Adrian Chadd
> Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx()
> To: "Barney Cordoba"
> Cc: "Luigi Rizzo" , freebsd-net@freebsd.org
> Date: Thursday, January 17, 2013, 11:48 AM
> There's also the subtle race
> condition in TX
--- On Thu, 1/17/13, Adrian Chadd wrote:
> From: Adrian Chadd
> Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx()
> To: "Luigi Rizzo"
> Cc: "Barney Cordoba" , freebsd-net@freebsd.org
> Date: Thursday, January 17, 2013, 2:04 PM
> On 17 January 2013 09:44, Luigi Rizzo
>
> wrot
> the problem i was actually seeing are slightly different,
> namely:
> - once the driver lags behind, it does not have a chance to
> recover
> even if there are CPU cycles available, because both
> interrupt
> rate and packets per interrupt are capped.
> - much worse, once the input stream s
On Fri, Jan 18, 2013 at 06:50:03AM -0800, Barney Cordoba wrote:
>
> > the problem i was actually seeing are slightly different,
> > namely:
> > - once the driver lags behind, it does not have a chance to
> > recover
> > ? even if there are CPU cycles available, because both
> > interrupt
> > ? ra
--- On Fri, 1/18/13, Luigi Rizzo wrote:
> From: Luigi Rizzo
> Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx()
> To: "Barney Cordoba"
> Cc: "Adrian Chadd" , freebsd-net@freebsd.org
> Date: Friday, January 18, 2013, 9:59 AM
> On Fri, Jan 18, 2013 at 06:50:03AM
> -0800, Barney
On Friday, January 18, 2013 9:30:40 am Barney Cordoba wrote:
>
> --- On Thu, 1/17/13, Adrian Chadd wrote:
>
> > From: Adrian Chadd
> > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx()
> > To: "Barney Cordoba"
> > Cc: "Luigi Rizzo" , freebsd-net@freebsd.org
> > Date: Thursday,
- Original Message -
> From: "Ivan Voras"
> To: freebsd-net@freebsd.org
> Sent: Friday, January 18, 2013 4:54:12 AM
> Subject: Re: VMware vmxnet2 driver
>
> On 14/01/2013 07:42, Bryan Venteicher wrote:
>
> > Any testing or performance data is welcome. For bulk TCP transfers,
> > if_vic
On Jan 18, 2013, at 6:12 AM, Sean Bruno wrote:
> On Fri, 2013-01-18 at 18:10 +0530, Venkat Duvvuru wrote:
>> Hi,
>> I have to submit some patches for Emulex's "oce" driver. Could you please
>> let me know if http://www.freebsd.org/send-pr.html is the correct way of
>> submitting them?
>>
>> /Ve
For my purposes, rescheduling the taskqueue means that other things
(such as TX, reset processing, other state handling, etc) can run
before the next pass at RX completion.
Also, IIRC, acquiring mutexes are one of those magic points where the
scheduler may decide to switch things around in a preem
On 18 January 2013 06:30, Barney Cordoba wrote:
> I don't see the distinction between the rx thread getting re-scheduled
> "immediately" vs introducing another thread. In fact you increase missed
> interrupts by this method. The entire point of interrupt moderation is
> to tune the intervals wher
On Friday, January 18, 2013 3:07:35 pm Adrian Chadd wrote:
> For my purposes, rescheduling the taskqueue means that other things
> (such as TX, reset processing, other state handling, etc) can run
> before the next pass at RX completion.
That only works if your taskqueue thread has a priority <= t
On Fri, Jan 18, 2013 at 1:03 PM, John Baldwin wrote:
> On Friday, January 18, 2013 3:07:35 pm Adrian Chadd wrote:
> > For my purposes, rescheduling the taskqueue means that other things
> > (such as TX, reset processing, other state handling, etc) can run
> > before the next pass at RX completion
16 matches
Mail list logo
