On Wed, Nov 6, 2019 at 10:20 AM Ilya Maximets <i.maxim...@ovn.org> wrote:
>
> On 06.11.2019 18:56, William Tu wrote:
> > On Wed, Nov 06, 2019 at 01:50:58PM +0100, Ilya Maximets wrote:
> >> On 05.11.2019 22:20, Ben Pfaff wrote:
> >>> On Tue, Nov 05, 2019 at 09:54:08PM +0100, Ilya Maximets wrote:
> >>>> 'xdpmode' is part of 'options', not the 'other_config'.
> >>>>
> >>>> CC: William Tu <u9012...@gmail.com>
> >>>> Fixes: 0de1b425962d ("netdev-afxdp: add new netdev type for AF_XDP.")
> >>>> Signed-off-by: Ilya Maximets <i.maxim...@ovn.org>
> >>>
> >>> It's not clear to me whether the options related to XDP and DPDK and PMD
> >>> consistently follow the intended convention.  The intention is that
> >>> options is for settings that are specific to a particular configured
> >>> interface type, and other-config is for options independent of the
> >>> interface type.
> >>
> >> 'options'      goes to  netdev_set_config().
> >> 'other_config' goes to  dpif_set_port_config().
> > I think you mean dpif_netdev_set_config
>
> Nope, I mean dpif_set_port_config() --> dpif_netdev_port_set_config()
> call sequence.
>
> dpif_netdev_set_config() is called from dpif_set_config() and uses
> global 'other_config', not the one from 'Interface' table.
>

yes, you're right.

> >
> >>
> >> And that dictates the rules of how we're using them.
> >>
> >> 'options' are used to store configuration options that needs to be
> >> applied to netdev itself. Those are number of HW queues, different
> >> work modes, numbers of HW descriptors, etc.
> >>
> >> 'other_config' is only used by dpif-netdev and stores per-port
> >> datapath configurations like enabling/disabling flow caches for
> >> particular port or pinning of netdev rx queues to pmd threads
> >> (this is actually the full list of currently supported configs).
> >>
> >> I agree that vswitch.xml might be better structured. For example,
> >> we could make more subcategories for afxdp, dpdk and vhost-user
> >> options to make the list more visual in man pages. It's not fully
> >> clear how to separate 'other_config's. And I'm also not really
> >> comfortable with using "PMD" abbreviation for "netdev that works
> >> in polling mode/interface that requires polling", but I have no
> >
> > I agree. "PMD" is very confusing, especially "Driver".
> > How about poll-mode netdev?
>
> Maybe 'poll mode interface' or something like that.
> 'netdev' is not a user-friendly word.
>
> >
> >> good ideas for short and meaningful replacement.
> >>
> >> What we can do is following:
> >>
> >>         PMD (Poll Mode Driver) Options:
> >>           options : n_rxq             optional string <...>
> >>
> >>           PMD Options: dpdk only:
> >>             options : dpdk-devargs      optional string
> >>             options : n_rxq_desc        optional string, <...>
> >>             options : n_txq_desc        optional string, <...>
> >>
> >>           PMD Options: dpdkvhostuserclient only:
> >>             options : vhost-server-path optional string
> >>             options : dq-zero-copy      optional string, <...>
> >>             options : tx-retries-max    optional string, <...>
> >>
> >>           PMD Options: afxdp only:
> >>             options : xdpmode           optional string, <...>
> >>             options : use-need-wakeup   optional string, <...>
> >>
> >>         Userspace Datapath Configuration:
> >>           other_config : emc-enable   optional string, <...>
> >>
> >>           Userspace Datapath Configuration: PMD only:
> >>             other_config : pmd-rxq-affinity  optional string
> >>
> >> Suggestions are welcome.
> >>
> >> Here we can see that all "PMD" netdevs should somehow support n_rxq
> >> option and it might make sense to pass it via other_config, but this
> >> doesn't fit existing code structure, i.e. will probably have to make
> >> an additional netdev interface like netdev_set_rx_multiq() for passing
> >> that value from the dpif (analogue of existing netdev_set_tx_multiq()).
> >> Another point is that not all the netdevs are "PMD" netdevs, so this
> >> option still kind of netdev specific.
> >>
> > Good idea, I think it's much clearer.
>
> You mean restructuration of a man page (vswitch.xml) ?
yes, I mean the restructure of man page.

William
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to