Re: [net] protecting interfaces from races between control and data ?

2013-08-07 Thread Luigi Rizzo
On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels wrote: > I'm replying to one of the last messages of this thread, but in part going > back to the beginning; then I'm following up on Andre's proposal. > > Luigi wrote: > > i am slightly unclear of what mechanisms we use to prevent races > > between int

Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets

2013-08-07 Thread John Baldwin
On Monday, August 05, 2013 6:49:01 am Meny Yossefi wrote: > John, > > Will this be committed to 9.2 as well ? Yes, I committed it yesterday. -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ne

Re: BPF_MISC+BPF_COP and BPF_COPX

2013-08-07 Thread Darren Reed
On 5/08/2013 5:12 AM, Mindaugas Rasiukevicius wrote: > Hello, > > I would like propose new BPF instructions for the misc category: BPF_COP > and BPF_COPX. It would provide a capability of calling an external > function - think of BPF "coprocessor". No. A BPF program is an entity that can be veri

Re: BPF_MISC+BPF_COP and BPF_COPX

2013-08-07 Thread Mindaugas Rasiukevicius
Alexander Nasonov wrote: > > Yes, I may want to keep the state in the memory store or pass the > > arguments through it, since the accumulator might not be enough. > > You have access to a whole packet, why do you need to pass additional > arguments through the store? I'm worried about introducin

Re: BPF_MISC+BPF_COP and BPF_COPX

2013-08-07 Thread Mindaugas Rasiukevicius
Darren Reed wrote: > > > > I would like propose new BPF instructions for the misc category: BPF_COP > > and BPF_COPX. It would provide a capability of calling an external > > function - think of BPF "coprocessor". > > No. > You do not have to use it. > A BPF program is an entity that can be v

Re: [net] protecting interfaces from races between control and data ?

2013-08-07 Thread Andre Oppermann
On 07.08.2013 09:18, Luigi Rizzo wrote: On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels mailto:m...@karels.net>> wrote: Jumping to (near) the end of the thread, I like most of Andre's proposal. Running with minimal locks at this layer is an admirable goal, and I agree with most of what wa

Re: [net] protecting interfaces from races between control and data ?

2013-08-07 Thread Scott Long
On Aug 7, 2013, at 2:00 PM, Andre Oppermann wrote: > On 07.08.2013 09:18, Luigi Rizzo wrote: >> On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels > > wrote: >>Jumping to (near) the end of the thread, I like most of Andre's proposal. >>Running with minimal locks at this

Re: BPF_MISC+BPF_COP and BPF_COPX

2013-08-07 Thread Alexander Nasonov
Mindaugas Rasiukevicius wrote: > Why is it a problem? Given that the byte-code and the functions would come > from the same source, some coupling seems natural to me. It is simplistic > anyway: some already parsed offsets or values could be passed through the > memory store. You surely have some

Re: [net] protecting interfaces from races between control and data ?

2013-08-07 Thread Adrian Chadd
On 7 August 2013 13:08, Scott Long wrote: > An even rore relevant difference is that taskqueues have a much stronger > management API. Ithreads can only be scheduled by generating a hardware > interrupt, > can only be drained by calling bus_teardown_intr(), and cannot be paused. > Taskqueues

Re: [net] protecting interfaces from races between control and data ?

2013-08-07 Thread Andre Oppermann
On 07.08.2013 22:48, Adrian Chadd wrote: On 7 August 2013 13:08, Scott Long wrote: An even rore relevant difference is that taskqueues have a much stronger management API. Ithreads can only be scheduled by generating a hardware interrupt, can only be drained by calling bus_teardown_intr(), a

Re: [net] protecting interfaces from races between control and data ?

2013-08-07 Thread Tim Kientzle
On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote: > The driver supplies a TX frame transmit function (mostly like if_transmit > today) which does all locking and multi-queue handling internally (driver > owned. This gives driver writers the freedom to better adjust to different > hardware commu

Re: [net] protecting interfaces from races between control and data ?

2013-08-07 Thread Tim Kientzle
On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote: > The driver supplies a TX frame transmit function (mostly like if_transmit > today) which does all locking and multi-queue handling internally (driver > owned. This gives driver writers the freedom to better adjust to different > hardware commu