DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Ilya Maximets <i.maximets@ovn.org>,
	Ori Kam <orika@nvidia.com>, Ivan Malov <Ivan.Malov@oktetlabs.ru>,
	Eli Britstein <elibr@nvidia.com>,
	Smadar Fuks <smadarf@marvell.com>,
	Hyong Youb Kim <hyonkim@cisco.com>,
	Kishore Padmanabha <kishore.padmanabha@broadcom.com>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Jerin Jacob <jerinj@marvell.com>, John Daley <johndale@cisco.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	olivier.matz@6wind.com, shahafs@nvidia.com,
	david.marchand@redhat.com, Rony Efraim <ronye@nvidia.com>
Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: clarify flow action PORT ID semantics
Date: Wed, 9 Jun 2021 17:31:08 +0300	[thread overview]
Message-ID: <e3acc82f-8e8b-eaea-27f3-483b8642e73d@oktetlabs.ru> (raw)
In-Reply-To: <3024930.R5H54lJN0W@thomas>

On 6/8/21 9:49 PM, Thomas Monjalon wrote:
> 08/06/2021 18:32, Andrew Rybchenko:
>> On 6/8/21 7:13 PM, Thomas Monjalon wrote:
>>> We will be at least 4 tomorrow Wednesday 3pm UTC.
>>> Everybody is welcome to join the community meeting:
>>> 	https://zoom.us/j/93391811485
>> Invite has July, 7. Typo?
> Yes was a typo, sorry.
> The invite was updated to tomorrow Wednesday June 9th.

Some input for the meeting. Done very quickly and a bit
late, but I hope still useful for the discussion.

Below is a very quick review of the ethdev API in attempt to understand
meaning of various functions if representor is a real ethdev port or
a shadow (configuration interface) of represented entity (VF, PF, SF
and may be even network port).

1. API with port_id+queue_id does not make sense if representor is
   a shadow of VF. Queues are fully controlled by guest OS.
    - rte_eth_tx_done_cleanup()
    - rte_eth_dev_rx_intr_enable()
    - rte_eth_dev_rx_intr_disable()
    - rte_eth_dev_rx_intr_ctl_q()
    - rte_eth_dev_rx_intr_ctl_q_get_fd()
    - rte_eth_set_queue_rate_limit()
    - rte_eth_add_rx_callback()
    - rte_eth_add_first_rx_callback()
    - rte_eth_remove_rx_callback()
    - rte_eth_add_tx_callback()
    - rte_eth_remove_tx_callback()
    - rte_eth_rx_queue_setup()
    - rte_eth_rx_hairpin_queue_setup()
    - rte_eth_tx_queue_setup()
    - rte_eth_tx_hairpin_queue_setup()
    - rte_eth_dev_rx_queue_start()
    - rte_eth_dev_rx_queue_stop()
    - rte_eth_dev_tx_queue_start()
    - rte_eth_dev_tx_queue_stop()
    - rte_eth_rx_queue_info_get()
    - rte_eth_tx_queue_info_get()
    - rte_eth_dev_set_tx_queue_stats_mapping()
    - rte_eth_dev_set_rx_queue_stats_mapping()
    - rte_eth_dev_set_vlan_strip_on_queue()
    - rte_eth_dev_rss_reta_update()
    - rte_eth_dev_rss_reta_query()
    - rte_eth_rx_burst_mode_get()
    - rte_eth_tx_burst_mode_get()
    - rte_eth_get_monitor_addr()
    - rte_eth_rx_burst()
    - rte_eth_rx_queue_count()
    - rte_eth_rx_descriptor_done()
    - rte_eth_rx_descriptor_status()
    - rte_eth_tx_descriptor_status()
    - rte_eth_tx_burst()
    - rte_eth_tx_prepare()
    - rte_eth_tx_buffer_flush()
    - rte_eth_tx_buffer()
    - rte_eth_dev_pool_ops_supported()
   Of course, we can say that representor port_id is a real
   ethdev port in this case, but it looks inconsistent.

2. Some API functions are essential in ethdev port life-cycle.

    2.1) rte_eth_dev_configure() is required to be real if
         representors are used for HW offload to receive
         slow path traffic. It configures real ethdev port
         queues, offloads, steering, interrupts etc.
         It never configures represented function (VF).

    2.2) rte_eth_dev_close() closes ethdev port itself (not VF)

    2.3) rte_eth_dev_start()/rte_eth_dev_stop() are required
         to be real similar to rte_eth_dev_configure()

    2.4) rte_eth_dev_info_get() could be a mixture in fact

3. A number of functions makes sense in both cases and
   looks a bit more natural if representor is a shadow of
   represented function (e.g. VF)

    3.1) rte_eth_dev_set_link_up()/rte_eth_dev_set_link_down()
         to administratively control if a VF can send/receive
         traffic.

    3.2) rte_eth_dev_reset() to enforce represented function
         reset to apply new settings.

    3.3) rte_eth_promiscuous_enable()/rte_eth_promiscuous_disable()/
         rte_eth_promiscuous_get()/rte_eth_allmulticast_enable()/
         rte_eth_allmulticast_disable()/rte_eth_allmulticast_get()
         to control if represented entity can receive corresponding
         traffic

    3.4) rte_eth_link_get()/rte_eth_link_get_nowait() ???

    3.5) rte_eth_macaddr_get()/rte_eth_dev_default_mac_addr_set()
         to provide and control administratively configured
         (and possibly enforced) MAC address of the represented entity

    3.6) rte_eth_dev_vlan_filter() can control (enforced?) VLAN
         filtering on represented entity

    3.7) rte_eth_dev_set_vlan_ether_type()/rte_eth_dev_set_vlan_pvid()
         may be used to configure transparent VLAN insertion
         (doable using RTE flow API VLAN_PUSH on transfer level)

    3.8) rte_eth_dev_set_vlan_offload()/rte_eth_dev_get_vlan_offload()
         may be used to control transparent VLAN stripping
         (doable using RTE flow API VLAN_POP on transfer level)
         See filter above.

    3.9) rte_eth_led_on()/rte_eth_led_off()
         makes sense for network port representors only

    3.10) rte_eth_fec_get_capability()/rte_eth_fec_get()/rte_eth_fec_set()
          makes sense for network port representors only

    3.11) rte_eth_dev_flow_ctrl_get()/rte_eth_dev_flow_ctrl_set()
          rte_eth_dev_priority_flow_ctrl_set()
          makes sense for network port representors only

    3.12) rte_eth_dev_mac_addr_add()/rte_eth_dev_mac_addr_remove()
          to control allowed MAC addresses for represented entity

    3.13) rte_eth_dev_udp_tunnel_port_add()/
          rte_eth_dev_udp_tunnel_port_delete()
          to administratively control UDP tunnels configuration and
          inform represented entity (set allowed entries)

    3.14) rte_eth_dev_set_mc_addr_list() to control allowed groups
          membership

4. Another group of functions which make sense in both cases, but
   more natural if representor is a real port.

    4.1) rte_eth_stats_get()/rte_eth_stats_reset()
         First of all, these stats report how many packets/bytes are
         received/sent by the DPDK application including per-queue
         figures.
         Of course, it makes sense for represented entity as well,
         but does not look as a primary meaning.

    4.2) rte_eth_xstats_get_names()/rte_eth_xstats_get()/
         rte_eth_xstats_get_names_by_id()/rte_eth_xstats_get_by_id()/
         rte_eth_xstats_get_id_by_name()/rte_eth_xstats_reset()
         similar to standard stats since include standard stats.
         Could provide information for both cases simultaneously in fact.

    4.3) rte_eth_dev_get_supported_ptypes()/rte_eth_dev_set_ptypes()
         it says what classification of packets DPDK app will see on Rx

    4.4) rte_eth_dev_get_mtu()/rte_eth_dev_set_mtu() since it is
         tightly related to size of Rx buffers and Rx offloads
         configuration, but definitely makes sense for represented
         entity.

    4.5) rte_eth_dev_callback_register()/rte_eth_dev_callback_unregister()
         seems to be more natural if representor is a real ethdev port

    4.6) rte_eth_dev_rss_hash_update()/rte_eth_dev_rss_hash_conf_get()
         but it could make sense for represented entity if we'd like
         to enforce something (unclear why we need it)

5. It does not matter for a number of functions since talking to HW anyway
    - rte_eth_dev_fw_version_get()
    - rte_eth_dev_get_reg_info()
    - rte_eth_dev_get_eeprom_length()
    - rte_eth_dev_get_eeprom()
    - rte_eth_dev_set_eeprom()
    - rte_eth_dev_get_module_info()
    - rte_eth_dev_get_module_eeprom()
    - rte_eth_timesync_enable()
    - rte_eth_timesync_disable()
    - rte_eth_timesync_read_rx_timestamp()
    - rte_eth_timesync_read_tx_timestamp()
    - rte_eth_timesync_adjust_time()
    - rte_eth_timesync_read_time()
    - rte_eth_timesync_write_time()
    - rte_eth_read_clock()
    - rte_eth_dev_hairpin_capability_get()
    - rte_eth_representor_info_get()

6. Not covered
    - rte_eth_dev_uc_hash_table_set()
    - rte_eth_dev_uc_all_hash_table_set()
    - rte_eth_mirror_rule_set()
    - rte_eth_mirror_rule_reset()
    - rte_eth_dev_get_dcb_info()
    - rte_eth_dev_get_sec_ctx()

Andrew.

  reply	other threads:[~2021-06-09 14:31 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-01 11:14 Ivan Malov
2021-06-01 12:10 ` Ilya Maximets
2021-06-01 13:24   ` Eli Britstein
2021-06-01 14:35     ` Andrew Rybchenko
2021-06-01 14:44       ` Eli Britstein
2021-06-01 14:50         ` Ivan Malov
2021-06-01 14:53         ` Andrew Rybchenko
2021-06-02  9:57           ` Eli Britstein
2021-06-02 10:50             ` Andrew Rybchenko
2021-06-02 11:21               ` Eli Britstein
2021-06-02 11:57                 ` Andrew Rybchenko
2021-06-02 12:36                 ` Ivan Malov
2021-06-03  9:18                   ` Ori Kam
2021-06-03  9:55                     ` Andrew Rybchenko
2021-06-07  8:28                       ` Thomas Monjalon
2021-06-07  9:42                         ` Andrew Rybchenko
2021-06-07 12:08                           ` Ori Kam
2021-06-07 13:21                             ` Ilya Maximets
2021-06-07 16:07                               ` Thomas Monjalon
2021-06-08 16:13                                 ` Thomas Monjalon
2021-06-08 16:32                                   ` Andrew Rybchenko
2021-06-08 18:49                                     ` Thomas Monjalon
2021-06-09 14:31                                       ` Andrew Rybchenko [this message]
2021-06-01 14:49     ` Ivan Malov
2021-06-01 14:28   ` Ivan Malov
2021-06-02 12:46     ` Ilya Maximets
2021-06-02 16:26       ` Andrew Rybchenko
2021-06-02 17:35         ` Ilya Maximets
2021-06-02 19:35           ` Ivan Malov
2021-06-03  9:29             ` Ilya Maximets
2021-06-03 10:33               ` Andrew Rybchenko
2021-06-03 11:05                 ` Ilya Maximets
2021-06-03 11:29               ` Ivan Malov
2021-06-07 19:27                 ` Ilya Maximets
2021-06-07 20:39                   ` Ivan Malov
2021-06-25 13:04       ` Ferruh Yigit
2021-06-02 12:16   ` Thomas Monjalon
2021-06-02 12:53     ` Ilya Maximets
2021-06-02 13:10     ` Andrew Rybchenko
2021-09-03  7:46 ` [dpdk-dev] [PATCH v1] " Andrew Rybchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3acc82f-8e8b-eaea-27f3-483b8642e73d@oktetlabs.ru \
    --to=andrew.rybchenko@oktetlabs.ru \
    --cc=Ivan.Malov@oktetlabs.ru \
    --cc=ajit.khaparde@broadcom.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=elibr@nvidia.com \
    --cc=ferruh.yigit@intel.com \
    --cc=hyonkim@cisco.com \
    --cc=i.maximets@ovn.org \
    --cc=jerinj@marvell.com \
    --cc=johndale@cisco.com \
    --cc=kishore.padmanabha@broadcom.com \
    --cc=olivier.matz@6wind.com \
    --cc=orika@nvidia.com \
    --cc=ronye@nvidia.com \
    --cc=shahafs@nvidia.com \
    --cc=smadarf@marvell.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).