From owner-freebsd-wireless@FreeBSD.ORG Sun Feb 24 06:36:41 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 449B0920 for ; Sun, 24 Feb 2013 06:36:41 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm11.bullet.mail.bf1.yahoo.com (nm11.bullet.mail.bf1.yahoo.com [98.139.212.170]) by mx1.freebsd.org (Postfix) with SMTP id D693C16EA for ; Sun, 24 Feb 2013 06:36:40 +0000 (UTC) Received: from [98.139.215.142] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 24 Feb 2013 06:30:07 -0000 Received: from [98.139.211.205] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 24 Feb 2013 06:30:07 -0000 Received: from [127.0.0.1] by smtp214.mail.bf1.yahoo.com with NNFMP; 24 Feb 2013 06:30:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1361687407; bh=m6tpVWdjJ+DEdKTB9H0k/LPJ5DtE8K0oVbxSV1AF3zY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:X-Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=QKXg9Xquh50lWHr5y/Yn0EDH6Dh+lzG5/cgJEQ6yBEZ+eNV8dYgYlCouJjktqn+D1amTBxlSnAxVgamHSHq9RZtVSqIrQtw7f40sYw8RphQYMIY/2j/WXxON4oY01xcgmudy87EWyo8kLHH+dKF/FOZ8DVjhUE2KF+/qq1CVWUM= X-Yahoo-Newman-Id: 37121.80220.bm@smtp214.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cSlnQPYVM1mhhWwDYZFPCny5Ha_macXfnmVCA_E3d4EBOde p52gLuBgk5QQHmJ9p5ETaGy2tap6ieJ5CgnPAdRUXvkjAxVc8At7074dI_Wy L6HsmIn_OHcscQ0RkEFUDHFkRoKifxLU5RSKTFT.ES0nfuUptSCX9AqUN3Z0 YKRM5Pdf7QbsQCZxNPJqY5X2m1diKUwlqeRgwqQn0xebAK8THPrmbGlWJGBt PGUisNoVZ5YTNK.8bKPJl1nTE0xlrtFhd9oAFikUF2hZBx51S6h3BEU_knm_ 6eE8eSqOKM64EyumDMoRjqfvwORe6DMJLb.OAuQkk3FxpIW.N6e7AwWGnr6g cHd1.PMrTkRGJE1x3d0YDn8q2xjDDBNKCTn4wy2kp_BCdG5TsfZE5IVC8iTj w5S5jIZDszRMpcNY3f0zqdosvJOV1tCbqCWdgBdZyMn8DGvVi.Dk0lqIQJ7Z BP_Cw9DzrOofI29VtSCw- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-da0-f42.google.com (moonlightakkiy@209.85.210.42 with plain) by smtp214.mail.bf1.yahoo.com with SMTP; 23 Feb 2013 22:30:06 -0800 PST Received: by mail-da0-f42.google.com with SMTP id z17so997318dal.29 for ; Sat, 23 Feb 2013 22:30:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.66.9.2 with SMTP id v2mr12725834paa.18.1361687405930; Sat, 23 Feb 2013 22:30:05 -0800 (PST) Received: by 10.68.52.170 with HTTP; Sat, 23 Feb 2013 22:30:05 -0800 (PST) Date: Sat, 23 Feb 2013 23:30:05 -0700 Message-ID: Subject: Re: [RFT] net80211 TX serialisation, take #4 From: PseudoCylon To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 06:36:41 -0000 > ------------------------------ > > Message: 12 > Date: Fri, 22 Feb 2013 17:18:44 -0800 > From: Adrian Chadd > To: freebsd-wireless@freebsd.org > Subject: Re: [RFT] net80211 TX serialisation, take #4 > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On 22 February 2013 15:25, Adrian Chadd wrote: > > So, this is all pretty terrible. The only sane solution for now is to > make my VAP TX lock an IC TX lock,and grab said IC TX lock for all > VAPs. That way the driver can grab the IC TX lock when it's doing > deferred sends and it'll be sure the lock is held when it decides to > grab/increment sequence numbers from ni->ni_txseqs[]. I don't think lock(); ni->ni_txseqs[]++; unlock(); can fix the problem because no one can guarantee which process/thread grabs the lock next. i.e. concurrently, without lock, - Thread A is processing packet seq#1 - Thread B is processing packet seq#2 When the time to do ni_txseqs[]++, how can we guarantee thread A grabs the lock before thread B? In other word, if thread A always grabs the lock first, we don't need to serialize the Tx, do we? > * .. and do this without tearing my hair out. The sequence will be messed up during moving packets from one queue to another, i.e from driver queue to hardware queue. As long as packets are in a queue (in a linked list) sequence won't change unless we explicitly write such code. So... Saving your hair option 1 tx() { for() { lock(); dequeue(m); /* assuming queue is in order */ ni_txseqs[]++ enqueue_working_queue(m); unlock(); ... process m ... lock(); /* * m may change here. * Whichever the thread does dequeues, m0 will be * the head of the queue, so sequence will be kept intact. * But, need to test if processing of m0 has been completed. */ dequeue_working_queue(m0); enqueue_driver_queue(m0); /* or hardware_queue() */ unlock(); } } This will keep sequence intact. Saving your hair option 2 Shave your head until you fix the problem. Hair will grow again, you know. No bad hair day is a bonus. AK