Messages in this thread | | | From | Brandon Streiff <> | Subject | RE: [PATCH net-next RFC 6/9] net: dsa: forward timestamping callbacks to switch drivers | Date | Fri, 29 Sep 2017 15:30:44 +0000 |
| |
> 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
| |