From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id BB8DB2B87 for ; Wed, 23 Jan 2019 13:24:09 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 5DAE6B4006A; Wed, 23 Jan 2019 12:24:08 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 23 Jan 2019 12:24:02 +0000 To: "WILLIAMS, CHARLES J" , Ferruh Yigit , Thomas Monjalon CC: "dev@dpdk.org" , Declan Doherty References: <1539157900-6208-1-git-send-email-arybchenko@solarflare.com> <1545200580-15467-1-git-send-email-arybchenko@solarflare.com> <10d9a6ab-d2b3-69a8-9155-2c8a50079564@intel.com> From: Andrew Rybchenko Message-ID: <24630eb0-26cb-9496-fc0e-6243953614fd@solarflare.com> Date: Wed, 23 Jan 2019 15:23:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24384.002 X-TM-AS-Result: No-12.798500-8.000000-10 X-TMASE-MatchedRID: PL66URbwWA8OwH4pD14DsPHkpkyUphL9FuNF4lJG6xvxxaAXDrCns9yi JF4Y8A5bahX4ipyY+l5BFJQa5SX9rPQYZJBBoF8R3FqOVb7PDELEGBoHKd3a+Ss/NM02Lj98642 uCOdFG25D+jzLG/8tD+kj+9vm/sSGn6xXepMP3Wfuykw7cfAoIILLh2/Jcc7eax+0dEYaKwwL3J nlO2X0PfekXIoW8BAcIeWOmF7CbXNdoH9yElve003dRRsh/h6y+IfriO3cV8QA6s2mIXI3kHpFp Kkcmr8As0bg2V8A+75gqs+aLRt0Y/ZomtZBUIXQEhGH3CRdKUWyNcEJTKJGJoqZ5BE37qCDuF0B EedRtW1c/Uf5dQsDPBNK1B6D+jB1Qbet2SV2daEVglQa/gMvfHzIY7d2+Tz9AnW+Tu2Fi4ZR18Q pzXStTi9BUTTI4YWlioFl5UK3cJ/SduMc6RnI+T5bo3ZLMFMHB+dff70WbjnhFSdXRfkAryy6wc 7QP68492grUwQgYZd5OPD8XJFfpL9ZdlL8eonaVnRXm1iHN1ZsZUSYh+N/e4ys15l0FKOgmkY+1 mLW7+nRrxAZoIpxKV0muC2QcKtEY4B+ULrnxwPUewEBsul0BorVUhXE25cRAA0pf04PreCPEnPv 9YBVoA== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--12.798500-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24384.002 X-MDID: 1548246249-wtArHBCyfUDC Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v1 0/3] ethdev: document more retained across restart X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 12:24:10 -0000 On 1/10/19 5:03 AM, WILLIAMS, CHARLES J wrote: > > > On 1/9/19 2:15 AM, Andrew Rybchenko wrote: >> On 1/8/19 5:52 PM, Ferruh Yigit wrote: >>> On 12/19/2018 6:22 AM, Andrew Rybchenko wrote: >>>> The patch series tries to improve documentation of what is retained >>>> across default restart. >>> Overall makes sense to add below items into retained list, only concern if is >>> there any PMD conflicts with these information, they should either updated with >>> this patch or at least notified about expectation change. >> >> From my point of view it is just clarification of the required behaviour. >> MTU is required because of flag which may be used to advertise that >> it is impossible to change in started state (otherwise the behaviour for >> different PMDs will be absolutely different). >> Default MAC is just cosmetics because of MAC address list is already >> mentioned and the only goal is to highlight since these are different >> features from the feature list point of view. >> All-multicast is a part of Rx mode. >> >> In fact I recall that net/bonding does not preserve all-multicast >> (CC maintainers). If there is an agreement to fix it, I can take >> a look - it should not be hard to fix. > > I don't think bonding does anything particular because the > all_multicast state of the bonding PMD isn't related to the slaves.  > Currently, it's up to the applications to correctly configure > multicast on the slaves. > May be I'm wrong but I think all-multicast handling should be similar to promiscuous mode handling in bonding: for all slaves in the case of round-robin, balance and broadcast, primary only in the case of active backup, TLB and ALB and when slave is added/removed in 802.3ad case. > On a side note, I don't think the registered multicast addresses are > preserved across PMD stop/start (unless this has been fixed recently). > Yes, that's true, but I think it is separate story. >> >> In general I think that notification is sufficient in this case. >> >>>> Andrew Rybchenko (3): >>>> ethdev: advertise MTU as retained across device stop/start >>>> ethdev: advertise default MAC as retained on device restart >>>> ethdev: highlight that all-multicast is retained on restart >>>> >>>> lib/librte_ethdev/rte_ethdev.h | 6 ++++-- >>>> 1 file changed, 4 insertions(+), 2 deletions(-) >>>> >>