1. Maybe we need to separate exception path from success path (allow
same path / separate path).
2. If a combination is not supported than configuration will fail....
(we can have a function to validate configured combinations, if
needed). It will be a "natural" limitation.
The real benefit is that API will be stable: adding a HW module will
mean implementing the new combinations (wo changing API for all the
other modules).
On 27 March 2017 at 15:20, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia-bell-labs.com> wrote:
>> >>>
>> >>> + /** 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
>
>
