On Thu, Feb 2, 2017 at 1:00 PM, Maxim Uvarov <maxim.uva...@linaro.org> wrote: > yes, the point it that classier or pktio should pass BPDUs and drop other > packets without cpu load if that possible... >
The ODP APIs are designed to be used by SW either to process packets or to configure the system for autonomous packet processing. To the extent that the ODP app is acting as a switch that needs to see and process BDPUs, they are just another type of packet. To the extent that the ODP app is acting at a higher level and simply needs to be informed of link state configuration, then we may need additional pktio APIs to manage these state changes and/or notifications resulting from them. Note that in the former case there will always be CPU load because ODP APIs run on CPUs. When ODP APIs are used to configure various types of autonomous processing (e.g., classification) then it is up to the ODP implementation whether that processing is done in SW on visible or invisible CPUs or some other HW path that doesn't involve any CPUs. > On 2 February 2017 at 20:01, Brian Brooks <brian.bro...@linaro.org> wrote: >> >> On Wed, Feb 1, 2017 at 9:41 AM, Bill Fischofer >> <bill.fischo...@linaro.org> wrote: >> > On Wed, Feb 1, 2017 at 9:29 AM, Maxim Uvarov <maxim.uva...@linaro.org> >> > wrote: >> >> I have some theoretical question to think... >> >> >> >> >> >> rstp on hardware switches supported with moving port into disabled mode >> >> where it do not accept packets but only stp packets can pass-thought to >> >> rstp daemon app which decided which where path is shorter and >> >> disables/enables certain ports. >> > >> > If the port is disabled the odp_pktio_t will never see any pkts until >> > it is re-enabled. The question is does this appear simply as a link >> > down indication or is there extra information that says it's down >> > because it's in a special mode. Currently we treat link state as a >> > boolean but it's clear that we'll want to extend that to en enum to >> > support more than two possible states that have different behaviors >> > associated with them. >> > >> >> >> >> How that app can be done with odp? >> > >> > Currently ODP provides APIs for examining link state but not for >> > manipulating it. That's one of the topics for the "production grade >> > ODP" discussions. >> > >> >> >> >> I think it might be classifier configuration or pktio settings. >> >> It might be worth to add additional states to pktio itself. >> > >> > These sort of things are properly done in the pktio rather than the >> > classifier, as they relate to the ability to see packets rather than >> > how to process them. >> >> One view of link state is a combination of MAC and PHY and (optional) >> pluggable transceiver link state. Some of these parts can be off-chip >> accessible via e.g. a 2 wire interface. Even if the link state is >> reported correctly by the off-chip device, there may be incorrect >> configuration or bus corruption on this slower control path! >> >> For STP and friends, there is a difference between link state and port >> state. The link must be up to receive the BPDUs. But, the port state >> is one of forwarding, discarding, learning, ... In some switch >> pipelines the ingress ACL path can be set up to match against BPDUs >> and send packet to the CPU (punt slow path)... and then drop every >> thing else received from the port. The control plane manages the >> protocol state machine and configures the hardware accordingly. >> >> Mapping this to ODP, I think the Packet IO link state remains >> untouched (if we think link state is something like link state as >> described above). Since what we call Classifier is kind of like the >> Match portion of Match+Action, I think all traffic received on a STP >> blocked port must be put on some queue to be received by the CPUs >> where they are dropped (unless a BPDU). To do better, there might >> need to be a model that describes the separation between the data >> plane and control plane; maybe scheduler is the interface between the >> two. >> >> >> >> >> Thanks, >> >> Maxim. > >
