Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752548AbdI2Pb1 (ORCPT ); Fri, 29 Sep 2017 11:31:27 -0400 Received: from mx0a-00010702.pphosted.com ([148.163.156.75]:54012 "EHLO mx0b-00010702.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751972AbdI2PbZ (ORCPT ); Fri, 29 Sep 2017 11:31:25 -0400 From: Brandon Streiff To: Florian Fainelli , "netdev@vger.kernel.org" CC: "linux-kernel@vger.kernel.org" , "David S. Miller" , Andrew Lunn , Vivien Didelot , Richard Cochran , Erik Hons Subject: RE: [PATCH net-next RFC 6/9] net: dsa: forward timestamping callbacks to switch drivers Thread-Topic: [PATCH net-next RFC 6/9] net: dsa: forward timestamping callbacks to switch drivers Thread-Index: AQHTOG5j0CHilU8JjEqeI6bBRHJcvaLKkMaAgAFX5CA= Date: Fri, 29 Sep 2017 15:30:44 +0000 Message-ID: References: <1506612341-18061-1-git-send-email-brandon.streiff@ni.com> <1506612341-18061-7-git-send-email-brandon.streiff@ni.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.164.62.183] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DM5PR04MB1261;6:5RdddwlnXzu+rNFLcHGki5uRcdbERLX5nzJ4dmi1MZcRmlDYkFBvH9lGpQ4Hzu44sr+zdnqkNB9c1Zq7imy8X7gOyONpUOK3r8e9c1IRUdsfCPClmN9BJg4xgO/ks/d4GQejeNkj09r7FiKo7KgRgTn6xQFOa4QzFl3f4O0gCQpj+J4LHog9CZ5CMwv5XSk4jffLbRl4a5Pt/f/u7+ICMO6cVrTr/hLp3v52B5sJMIOMKZ0YAGCdHqv5inK6Gsq0OqeTcSrICp8jmIHR1Mehq3RF+C8UCGUFgFgC+4EuGMKbILed99Wd1mHadoS00py7JDKmlt6uWyPbujgZ6NWveg==;5:0TCgNngPVSDTo1v3/GShANv8zL1ucOnpVVM1bs9K3n4pcKfDu1nGmvSXLu7uX0SVIZRfLWhVeEkoQyG3VLWt2/ytrzuhzVXV3gZKtq6b6MIesdDJQ3fTaGw6JsQKwBmUIEoA4AVEh6Jab5BRoZy7dA==;24:7oISMU7bgK0x8APOapYvWzjmyM6VGyYto/UUGoAUzoSa7LOyQfduoJcFLjxZh7QKyMv1WROoRB9isBN3nSzUwalUf8B/OUirBkfOcMKCtFs=;7:OBI+gWo2+rg/RUgTYDwFv9r6WXYlSlBmEuniV4m5tlClRBOwXgh8KjtEd5twY2udnFrnlZe/7YnKUtjrjMyodVV/qDdRVkP6AmHMG89QC6O2T2VTpvko+iu0GqdmVIEO3CXwCEfAUCkx4rs3HnEaW9vtieNNloDMzjiDyRbeyl/r4pVXUYMG52stJV/yitTJGKoDYE4XhIzwW2J+Lx9/FODCFUto8MRU4LQawLN/kIk= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI;SCL:-1;SFV:NSPM;SFS:(10019020)(6009001)(376002)(346002)(189002)(199003)(377454003)(74316002)(2906002)(3660700001)(316002)(33656002)(25786009)(2501003)(478600001)(81166006)(7736002)(14454004)(54906003)(4326008)(8676002)(81156014)(105586002)(6506006)(6116002)(3846002)(3280700002)(110136005)(5660300001)(77096006)(8936002)(9686003)(305945005)(54356999)(2950100002)(86362001)(76176999)(7696004)(106356001)(102836003)(6246003)(189998001)(66066001)(2900100001)(68736007)(55016002)(97736004)(50986999)(101416001)(39060400002)(53936002)(99286003)(6436002)(229853002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM5PR04MB1261;H:CO2PR04MB2184.namprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; x-ms-office365-filtering-correlation-id: e988966f-f864-4ebc-ee33-08d5074f0d1f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:DM5PR04MB1261; x-ms-traffictypediagnostic: DM5PR04MB1261: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DM5PR04MB1261;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DM5PR04MB1261; x-forefront-prvs: 0445A82F82 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2017 15:30:44.4769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR04MB1261 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-29_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=30 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=30 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709290223 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v8TFVjlg029255 Content-Length: 1384 Lines: 32 > From: Florian Fainelli [mailto:f.fainelli@gmail.com] > Sent: Thursday, September 28, 2017 12:40 PM > > Can we also have a fast-path bypass in case time stamping is not > supported by the switch so we don't have to even try to classify this > packet only to realize we don't have a port_rxtsamp() operation later? > You can either gate this with a compile-time option, or use e.g: a > static key or something like an early test? I was trying to follow the existing pattern for skb_defer_rx_timestamp, but that function be turned into a stub by not configuring NETWORK_PHY_TIMESTAMPING. Maybe a similar compile-time token is appropriate. > > > > - nskb = dst->rcv(skb, dev, pt); > > + nskb = dst->rcv(skb, dev, pt, &ds, &source_port); > > I don't think this is necessary, what dst->rcv() does is actually > properly assign skb->dev to the correct dsa slave network device, which > has the information about the port number already in its private context. Yes, looking in that private context seems like it'd be a better approach (and avoids having to touch all the taggers). I'll look into that further. > > + type = ptp_classify_raw(skb); > > + if (type == PTP_CLASS_NONE) > > + return; > > If we don't have a port_txtstamp option, is there even value in > classifying this packet? There isn't. This could also use a bypass just like the RX case. -- brandon