From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 6D72B594B for ; Tue, 21 Jul 2015 07:23:41 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 20 Jul 2015 22:23:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,513,1432623600"; d="scan'208";a="751257756" Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78]) by fmsmga001.fm.intel.com with ESMTP; 20 Jul 2015 22:23:39 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 21 Jul 2015 13:23:19 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.165]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.46]) with mapi id 14.03.0224.002; Tue, 21 Jul 2015 13:23:16 +0800 From: "Ouyang, Changchun" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH] virtio: fix the vq size issue Thread-Index: AQHQs9JlQEOaxBUIeEyxKL7zRjwCJJ3fbVEAgAPgnICAAIjiMP//7N4AgAG66eA= Date: Tue, 21 Jul 2015 05:23:16 +0000 Message-ID: References: <1435736930-26737-1-git-send-email-changchun.ouyang@intel.com> <82F45D86ADE5454A95A89742C8D1410E01D7DBAF@shsmsx102.ccr.corp.intel.com> <28751942.NtB1joDEOR@xps13> In-Reply-To: <28751942.NtB1joDEOR@xps13> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] virtio: fix the vq size issue X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 05:23:41 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Monday, July 20, 2015 6:42 PM > To: Ouyang, Changchun > Cc: Xu, Qian Q; Stephen Hemminger; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] virtio: fix the vq size issue >=20 > 2015-07-20 06:18, Ouyang, Changchun: > > Another thing burst into my thought. > > Can we think more about how to setup a mechanism to block those > patches which causes critical regression issue? >=20 > Yes. Non-regression tests are needed. As it must be done with many > hardwares and many configurations, it must be a shared effort. > As a first step, you can run some automated tests by yourself and > *manually* raise errors on the mailing lists. When it will work well, we = could > discuss about gathering test reports in a clean distributed way. > Note that this topic is already a work in progress by few people and a pu= blic > proposal should be done in few weeks. That's good.=20 >=20 > > I did review that patch before, but fail to realize it will break the b= asic > function of virtio PMD, it is my bad. > > (Can I send the nack to that patch even after it has been merged into > > dpdk.org?) >=20 > After being approved and merged, a nack has no effect. > Having a revert approved is the good way. I have acked Stephen's new patch. >=20 > > After that, we find that in our testing cycle, we spend time in > > investigating that and root the cause, and sent out the fixing patch on= July 1. > Keeping virtio basic functionality broken more than 20 days is bad thing = for > me. >=20 > It wouldn't be so long if these 3 simple things were done: > - use a better title: "virtio: fix Rx from Qemu" instead of a not meaning= ful "fix > the vq size issue" > - cc Stephen (I did it later) who did the original patch you wants to rev= ert > - have an acked-by from Huawei Xie who commented the patch >=20 > > If we can run a regression automation test with every patch set sent > > out to dpdk.org, and put those patches breaking any test cases Into > > failing-list and notify author, reviewer and maintainer, all those thin= gs > should be done before theirs being merged, then it will prevent from > merging the erroneous patch into mainline, and thus reduce most reverting > patch. >=20 > As explained above, it is planned and you can start running you own local= test > machine. But please do not spam the mailing list with automated mails fro= m > these tests.