[dpdk-dev] [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances

Thomas Monjalon thomas at monjalon.net
Wed May 8 13:15:54 CEST 2019


24/04/2018 08:41, Arnon Warshavsky:
> The purpose of this patch series is to cleanup the library code
> from paths that end up aborting the process,
> and move to checking error values, in order to allow the running process
> perform an orderly teardown or other mitigation of the event.
> 
> This patch modifies the majority of rte_panic calls
> under lib and drivers, and replaces them with a log message
> and an error return code according to context,
> that can be propagated up the call stack.
> 
> - Focus was given to the dpdk initialization path
> - Some of the panic calls within drivers were left in place where
>   the call is from within an interrupt or calls that are
>   on the data path,where there is no simple applicative
>   route to propagate the error to temination.
>   These should be handled by the driver maintainers..
> - local void functions with no api were changed to retrun a value
>   where needed
> - No change took place in example and test files
> - No change took place for debug assertions calling panic

I did a status of rte_panic/rte_exit calls in libs.

There are a lot of cleanups to do in EAL.
We may apply the same kind of solution for Linux, FreeBSD and Windows.

The status is described below in a kind of call tree:

librte_eal:

    int rte_eal_init
        rte_panic
        void rte_config_init
            rte_panic
            void rte_eal_config_create
                rte_exit
                rte_panic
            void rte_eal_config_attach
                rte_panic
            void rte_eal_config_reattach
                rte_panic
        void eal_thread_init_master
            rte_panic
        -> internal change
    
    int rte_eal_remote_launch
            rte_panic
                -> add a return code
    
    eal_thread_loop
        rte_panic
            -> abort thread?
    eal_intr_thread_main
        rte_panic
            -> abort thread?
    
    int get_hugepage_dir
        rte_panic
            -> no public API
    
    uint64_t rte_get_timer_cycles
    uint64_t rte_get_hpet_hz
    uint64_t rte_get_hpet_cycles
        rte_panic
            -> return 0 / no API change
    
librte_mempool:
    void rte_mempool_*
        RTE_LIBRTE_MEMPOOL_DEBUG
            rte_panic

librte_mbuf:
    void rte_mbuf_sanity_check
        rte_panic

librte_lpm:
    RTE_LIBRTE_LPM_DEBUG
        VERIFY_DEPTH
            rte_panic

librte_acl:
    RTE_ACL_VERIFY
        rte_panic
            -> debug check? / no API change?

librte_sched:
    void debug_check_queue_slab
        rte_panic
            -> debug assert

void rte_metrics_init
        rte_exit
            -> API breakage

librte_kni:
    struct rte_kni *rte_kni_alloc
        void kni_fifo_init
            rte_panic
                -> no public API change

librte_eventdev:
    struct rte_eventdev *rte_event_pmd_vdev_init
        rte_panic
            -> no API change
    int rte_event_pmd_pci_probe
        rte_panic
            -> no API change





More information about the dev mailing list