i am slightly unclear of what mechanisms we use to prevent races
between interface being reconfigured (up/down/multicast setting, etc,
all causing reinitialization of the rx and tx rings) and
i) packets from the host stack being sent out;
ii) interrupts from the network card being processed.
I th
On Aug 5, 2013, at 2:23 AM, Luigi Rizzo wrote:
> i am slightly unclear of what mechanisms we use to prevent races
> between interface being reconfigured (up/down/multicast setting, etc,
> all causing reinitialization of the rx and tx rings) and
>
> i) packets from the host stack being sent out;
John,
Will this be committed to 9.2 as well ?
-Meny
-Original Message-
From: j...@freebsd.org [mailto:j...@freebsd.org]
Sent: Thursday, July 25, 2013 7:35 PM
To: Meny Yossefi; j...@freebsd.org; freebsd-net@FreeBSD.org; j...@freebsd.org
Subject: Re: kern/180430: [ofed] [patch] Bad UDP
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
By "inconsistent state" i just mean that the driver is not actually up, but the
IFF_UP flag is set. The problem is that when the interface is brought up by the
user after that (ifconfig lagg0 up), the part of the code that adds the default
subnet broadcast routes checks IFF_UP and sees it is set
- Original Message -
> i am slightly unclear of what mechanisms we use to prevent races
> between interface being reconfigured (up/down/multicast setting, etc,
> all causing reinitialization of the rx and tx rings) and
>
> i) packets from the host stack being sent out;
> ii) interrupts f
On 5 August 2013 07:59, Bryan Venteicher wrote:
> What I've done in my drivers is:
> * Lock the core mutex
> * Clear IFF_DRV_RUNNING
> * Lock/unlock each queue's lock
.. and I think that's the only sane way of doing it.
I'm going to (soon) propose something similar for cxgbe/ixgbe as we
u
On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote:
> On 5 August 2013 07:59, Bryan Venteicher
> wrote:
>
> > What I've done in my drivers is:
> > * Lock the core mutex
> > * Clear IFF_DRV_RUNNING
> > * Lock/unlock each queue's lock
>
> .. and I think that's the only sane way of doing it.
On 08/05/13 09:15, Luigi Rizzo wrote:
> On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote:
>
>> On 5 August 2013 07:59, Bryan Venteicher
>> wrote:
>>
>>> What I've done in my drivers is:
>>> * Lock the core mutex
>>> * Clear IFF_DRV_RUNNING
>>> * Lock/unlock each queue's lock
>>
>> .. and
I'm travelling back to San Jose today; poke me tomorrow and I'll brain
dump what I did in ath(4) and the lessons learnt.
The TL;DR version - you don't want to grab an extra lock in the
read/write paths as that slows things down. Reuse the same per-queue
TX/RX lock and have:
* a reset flag that is
.. and I bet it's not a design pattern, and this is total conjecture on my part:
* the original drivers weren't SMP safe;
* noone really sat down and figured out how to correctly synchronise
all of this stuff;
* people did the minimum amount of work to keep the driver from
immediately crashing, bu
On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote:
> .. and I bet it's not a design pattern, and this is total conjecture on my
> part:
>
> * the original drivers weren't SMP safe;
> * noone really sat down and figured out how to correctly synchronise
> all of this stuff;
> * people did the mini
On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote:
> I'm travelling back to San Jose today; poke me tomorrow and I'll brain
> dump what I did in ath(4) and the lessons learnt.
>
> The TL;DR version - you don't want to grab an extra lock in the
> read/write paths as that slows things down. Reuse
Sigh, this ends up being ugly I'm afraid. I need some time to look at code
and think about it.
Jack
On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote:
> On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote:
>
> > I'm travelling back to San Jose today; poke me tomorrow and I'll brain
> > dump
On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote:
> Sigh, this ends up being ugly I'm afraid. I need some time to look at code
> and think about it.
>
>
actually the intel drivers seem in decent shape,
especially if we reuse IFF_DRV_RUNNING as the reset flag
and the core+queue lock in the control
No, brian said two things:
* the flag, protected by the core lock
* per-queue flags
-adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebs
What do you think about this change?
Cheers,
Jack
On Mon, Aug 5, 2013 at 10:58 AM, Luigi Rizzo wrote:
> On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote:
>
>> Sigh, this ends up being ugly I'm afraid. I need some time to look at
>> code and think about it.
>>
>>
> actually the intel drivers
On Aug 1, 2013, at 6:16 PM, John-Mark Gurney wrote:
> Joe Moog wrote this message on Thu, Aug 01, 2013 at 17:14 -0500:
>> On Aug 1, 2013, at 4:27 PM, Joe Moog wrote:
>>
>>> On Aug 1, 2013, at 3:55 PM, Ryan Stone wrote:
>>>
Have you tried using only two ports, but both from the NIC? My
> Date: Fri, 02 Aug 2013 09:36:30 +0200
> From: Steve Read
> To: freebsd-net@freebsd.org
> Subject: Re: Intel 4-port ethernet adaptor link aggregation issue
> Message-ID: <51fb617e.2090...@netasq.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 01.08.2013 20:07, Joe Moog
chris...@astron.com (Christos Zoulas) wrote:
> >> <...>
> >>
> >>BPF_STMT(BPF_MISC+BPF_COP, 0), /* A <- funcs[0](...) */
> >>
> >>typedef uint32_t(*bpf_copfunc_t)(struct mbuf *pkt,
> >>uint32_t A, uint32_t *M);
> >>
> >>int bpf_set_cop(bpf_ctx_t *c, bpf_copfunc_t funcs[], siz
On Mon, Aug 5, 2013 at 8:19 PM, Adrian Chadd wrote:
> No, brian said two things:
>
> * the flag, protected by the core lock
> * per-queue flags
>
i see no mentions on per-queue flags on his email.
This is the relevant part
What I've done in my drivers is:
* Lock the core mutex
On 05.08.2013 16:59, Bryan Venteicher wrote:
- Original Message -
i am slightly unclear of what mechanisms we use to prevent races
between interface being reconfigured (up/down/multicast setting, etc,
all causing reinitialization of the rx and tx rings) and
i) packets from the host st
On Mon, Aug 5, 2013 at 8:46 PM, Jack Vogel wrote:
> What do you think about this change?
>
>
looks good to me. but there is no need to rush, especially
it will be nice if all interested parties agree on an approach
and possibly even naming.
I do not have any specific test case but the problem ca
- Original Message -
> On Mon, Aug 5, 2013 at 8:19 PM, Adrian Chadd wrote:
>
> > No, brian said two things:
> >
> > * the flag, protected by the core lock
> > * per-queue flags
> >
>
> i see no mentions on per-queue flags on his email.
> This is the relevant part
>
Right, I just use
On 05.08.2013 19:36, Luigi Rizzo wrote:
On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote:
I'm travelling back to San Jose today; poke me tomorrow and I'll brain
dump what I did in ath(4) and the lessons learnt.
The TL;DR version - you don't want to grab an extra lock in the
read/write paths
Hello Alex,
Let's keep freebsd-net CCed in case there is any interest.
Alexander Nasonov wrote:
>
> I like the idea but I have some questions:
>
> 1. Why do you need access to scratch memory? Is your goal to keep a
> state for C code between cop calls? In this case, you can use
> the stand
On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote:
> On 05.08.2013 19:36, Luigi Rizzo wrote:
...
>
> [picking a post at random to reply in this thread]
> > tell whether or not we should bail out).
>
> Ideally we don't want to have any locks in the RX and TX path at all.
Ok i have r
27 matches
Mail list logo
