17/01/2018 11:11, Gaëtan Rivet: > A new suggestion about the syntax. > > On Tue, Jan 16, 2018 at 10:50:18PM +0800, Yuanhan Liu wrote: > > This patch documents the new devargs syntax, which is going to be > > implemented in DPDK v18.05. > > > > The new devargs proposal is introduced for having a consistent > > interface for: > > > > - whitelisting/blacklisting devices > > - identifying ports > > - attaching/detaching devices > > > > Please check the patch content for the details. Also, here is link > > for the background: > > http://dpdk.org/ml/archives/dev/2017-November/082600.html > > > > This syntax is suggestd by Thomas: > > http://dpdk.org/ml/archives/dev/2017-December/084234.html > > > > Signed-off-by: Yuanhan Liu <y...@fridaylinux.org> > > --- > > doc/guides/prog_guide/env_abstraction_layer.rst | 34 > > +++++++++++++++++++++++++ > > 1 file changed, 34 insertions(+) > > > > diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst > > b/doc/guides/prog_guide/env_abstraction_layer.rst > > index 34d871c..12f37f2 100644 > > --- a/doc/guides/prog_guide/env_abstraction_layer.rst > > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst > > @@ -213,6 +213,40 @@ device having emitted a Device Removal Event. In such > > case, calling > > callback. Care must be taken not to close the device from the interrupt > > handler > > context. It is necessary to reschedule such closing operation. > > > > +Devargs > > +~~~~~~~ > > + > > +The ``devargs`` can be used for whitelisting/blacklisting devices, > > identifying > > +DPDK ports and attaching/deatching devices. They all share the same syntax. > > + > > +It is split in 3 categories, where almost everything is optional key/value > > pairs: > > + > > +* bus (pci, vdev, vmbus, fslmc, etc) > > +* class (eth, crypto, etc) > > +* driver (i40e, mlx5, virtio, etc) > > + > > +The key/value pair describing the category scope is mandatory and must be > > the > > +first pair in the category properties. Example: bus=pci, must be placed > > before > > +id=0000:01:00.0. > > + > > +The syntax has below rules: > > + > > +* Between categories, the separator is a slash. > > +* Inside a category, the separator is a comma. > > +* Inside a key/value pair, the separator is an equal sign. > > +* Each category can be used alone. > > + > > +Here is an example with all categories:: > > + > > + > > bus=pci,id=0000:01:00.0/class=eth,mac=00:11:22:33:44:55/driver=PMD_NAME,driverspecificproperty=VALUE > > + > > +It can also be simple like below:: > > + > > + class=eth,mac=00:11:22:33:44:55 > > + > > 1/ > > All categories are named, their order is known, and their name comes > first.
The order of categories is known but some categories may be omitted. > It is thus possible to declare categories unambiguously without using > the field name first. > > > pci,id=0000:01:00.0/eth,mac=00:11:22:33:44:55/PMD_NAME,driverspecificproperty=VALUE > eth,mac=00:11:22:33:44:55 > pci,id=00:02.0 > > The only requirement for this to hold is for the layer names not to collide > (bus, dev, drivers), which seems like an easy enough requirement to follow. I don't like it for 2 reasons: - it is less explicit - it is less obvious to dispatch to parsers > ------------------------------- > > > +A device is identified when every properties are matched. Before device is > > +probed, only the bus category is relevant. > > + > > 2/ > > When using the following ID: > > class=eth,mac=00:11:22:33:44:55 > > The bus is skipped, as well as the driver. > Does that mean that it is allowed to skip any layer, as long as the > resulting match is unambiguous? > > What I mean is that a user could then do > > driver=net_ring > > To find the one port using the driver net_ring. I think yes, if there is only one net_ring device. > ------------------------------- > > 3/ > > The driver would generate a name for the eth_dev structure. > I guess it would be possible to identify the device with > > class=eth,name=net_ring0 > > Or something. Where does the rte_dev name appears? Is it a property > of the bus layer? Is it merged with the eth_dev name? If so, which one > will stay, the rte_dev name or the eth_dev name? EAL device and ethdev are different layers. There is no 1:1 mapping. So both must stay. rte_dev name should be a property of the bus layer.
