> >>>
> >>> +       /** Classifier destination CoS for IPSEC result events
> >>> +        *
> >>> +        *  Result events for successfully decapsulated packets are
> sent to
> >>> +        *  classification through this CoS. Other result events are
> sent to
> >>> +        *  'dest_queue'. This field is considered only when
> 'pipeline' is
> >>> +        *  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between
> any pktio
> >>> +        *  interface default CoS.
> >>> +        */
> >>> +       odp_cos_t dest_cos;
> >>
> >> Having multiple pieces of information needed for the same config
> >> suggests opportunities for simplification. Perhaps a scheme along the
> >> following lines:
> >>
> > enum odp_ipsec_next_t {
> >        ODP_IPSEC_NEXT_QUEUE = 0,
> >        ODP_IPSEC_NEXT_COS,
> >        ODP_IPSEC_NEXT_PKTIO,
> >        ODP_IPSEC_NEXT_TM,
> > } odp_ipsec_next_t;
> >
> >> typedef struct odp_ipsec_next_config_t {
> >         odp_ipsec_next_t next;
> >         union {
> >             odp_queue_t queue;
> >             odp_cos_t cos;
> >             odp_pktio_t pktio;
> >             odp_tm_queue_t tm_q;
> >         };
> >>
> >> } odp_ipsec_next_config_t;
> 
> Maybe this form will make it clearer:
> union {
>         struct {
>             odp_ipsec_dest_in_type_t dest_type;
> 
>             union {
>                 odp_queue_t queue;
>                 odp_cos_t cos;
>             } dest_val;
>         } inbound;
> 
>         struct {
>             odp_ipsec_dest_out_type_t dest_type;
> 
>             union {
>                 odp_queue_t queue;
>                 odp_pktio_t pktio;
>                 odp_tm_queue_t tm_q;
>             } dest_val;
>         } outbound;
>     } dest;
> 
> Yet, I still believe this model is limiting flexibility... maybe we
> need a framework with a generic way to connect different HW modules.
> 

See my answer for Bill about handle usage.

Actually, limiting flexibility is good for the spec. We can dictate in each 
step which other accelerators are possible next steps of a pipeline and how 
exceptions are handled.

E.g. today IPSEC spec specifies
* pktin -> IPSEC -> CLS -> queue

maybe tomorrow CLS would allow pipeline with DPI, and we'd extend to (with 
proper event format)
* pktin -> IPSEC -> CLS -> queue
                     |
                     +---> DPI -> queue


Even with a generic accelerator pipeline, only a few combinations would be 
actually useful or even possible to implement (with all the exception handling).


-Petri


Reply via email to