From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 682F6ADA7 for ; Fri, 12 Jun 2015 14:31:10 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 12 Jun 2015 05:31:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,601,1427785200"; d="scan'208";a="507205348" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by FMSMGA003.fm.intel.com with ESMTP; 12 Jun 2015 05:31:00 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.73]) by IRSMSX108.ger.corp.intel.com ([169.254.11.59]) with mapi id 14.03.0224.002; Fri, 12 Jun 2015 13:30:58 +0100 From: "Ananyev, Konstantin" To: "Wang, Liang-min" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support access device info Thread-Index: AQHQo4/Uz84r4LZBA0eIhB09B1a4pJ2nKH/wgAAL/ACAABF3kIAAg7QAgAD8UZA= Date: Fri, 12 Jun 2015 12:30:58 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836A08FD3@irsmsx105.ger.corp.intel.com> References: <1432946276-9424-1-git-send-email-liang-min.wang@intel.com> <1433948996-9716-1-git-send-email-liang-min.wang@intel.com> <1433948996-9716-2-git-send-email-liang-min.wang@intel.com> <2601191342CEEE43887BDE71AB97725836A08BA3@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725836A08BD4@irsmsx105.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support access device info X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 12:31:12 -0000 > -----Original Message----- > From: Wang, Liang-min > Sent: Thursday, June 11, 2015 10:51 PM > To: Ananyev, Konstantin; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support access= device info >=20 >=20 >=20 > > -----Original Message----- > > From: Ananyev, Konstantin > > Sent: Thursday, June 11, 2015 9:07 AM > > To: Wang, Liang-min; dev@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support acce= ss > > device info > > > > > > > > > -----Original Message----- > > > From: Wang, Liang-min > > > Sent: Thursday, June 11, 2015 1:58 PM > > > To: Ananyev, Konstantin; dev@dpdk.org > > > Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support > > > access device info > > > > > > Hi Konstantin, > > > > > > > -----Original Message----- > > > > From: Ananyev, Konstantin > > > > Sent: Thursday, June 11, 2015 8:26 AM > > > > To: Wang, Liang-min; dev@dpdk.org > > > > Cc: Wang, Liang-min > > > > Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support > > > > access device info > > > > > > > > Hi Larry, > > > > > > > > > -----Original Message----- > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Liang-Min > > > > > Larry Wang > > > > > Sent: Wednesday, June 10, 2015 4:10 PM > > > > > To: dev@dpdk.org > > > > > Cc: Wang, Liang-min > > > > > Subject: [dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support > > > > > access device info > > > > > > > > > > add new apis: > > > > > - rte_eth_dev_default_mac_addr_set > > > > > - rte_eth_dev_reg_leng > > > > > - rte_eth_dev_reg_info > > > > > - rte_eth_dev_eeprom_leng > > > > > - rte_eth_dev_get_eeprom > > > > > - rte_eth_dev_set_eeprom > > > > > - rte_eth_dev_get_ringparam > > > > > - rte_eth_dev_set_ringparam > > > > > > > > > > to enable reading device parameters (mac-addr, register, eeprom, > > > > > ring) based upon ethtool alike data parameter specification. > > > > > > > > > > Signed-off-by: Liang-Min Larry Wang > > > > > --- > > > > > lib/librte_ether/Makefile | 1 + > > > > > lib/librte_ether/rte_eth_dev_info.h | 80 +++++++++++++++++ > > > > > lib/librte_ether/rte_ethdev.c | 159 > > > > +++++++++++++++++++++++++++++++++ > > > > > lib/librte_ether/rte_ethdev.h | 158 > > > > ++++++++++++++++++++++++++++++++ > > > > > lib/librte_ether/rte_ether_version.map | 8 ++ > > > > > 5 files changed, 406 insertions(+) create mode 100644 > > > > > lib/librte_ether/rte_eth_dev_info.h > > > > > > > > > > diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefil= e > > > > > index c0e5768..05209e9 100644 > > > > > --- a/lib/librte_ether/Makefile > > > > > +++ b/lib/librte_ether/Makefile > > > > > @@ -51,6 +51,7 @@ SRCS-y +=3D rte_ethdev.c SYMLINK-y-include += =3D > > > > > rte_ether.h SYMLINK-y-include +=3D rte_ethdev.h SYMLINK-y-inclu= de > > > > > +=3D rte_eth_ctrl.h > > > > > +SYMLINK-y-include +=3D rte_eth_dev_info.h > > > > > > > > > > # this lib depends upon: > > > > > DEPDIRS-y +=3D lib/librte_eal lib/librte_mempool lib/librte_ring > > > > > lib/librte_mbuf diff --git a/lib/librte_ether/rte_eth_dev_info.h > > > > > b/lib/librte_ether/rte_eth_dev_info.h > > > > > new file mode 100644 > > > > > index 0000000..002c4b5 > > > > > --- /dev/null > > > > > +++ b/lib/librte_ether/rte_eth_dev_info.h > > > > > @@ -0,0 +1,80 @@ > > > > > +/*- > > > > > + * BSD LICENSE > > > > > + * > > > > > + * Copyright(c) 2015 Intel Corporation. All rights reserved. > > > > > + * All rights reserved. > > > > > + * > > > > > + * Redistribution and use in source and binary forms, with or = without > > > > > + * modification, are permitted provided that the following con= ditions > > > > > + * are met: > > > > > + * > > > > > + * * Redistributions of source code must retain the above co= pyright > > > > > + * notice, this list of conditions and the following discl= aimer. > > > > > + * * Redistributions in binary form must reproduce the above > > copyright > > > > > + * notice, this list of conditions and the following discl= aimer in > > > > > + * the documentation and/or other materials provided with = the > > > > > + * distribution. > > > > > + * * Neither the name of Intel Corporation nor the names of = its > > > > > + * contributors may be used to endorse or promote products > > derived > > > > > + * from this software without specific prior written permi= ssion. > > > > > + * > > > > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND > > > > CONTRIBUTORS > > > > > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, > > BUT > > > > NOT > > > > > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND > > > > FITNESS FOR > > > > > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE > > > > COPYRIGHT > > > > > + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, > > > > INCIDENTAL, > > > > > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES > > (INCLUDING, > > > > BUT NOT > > > > > + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; > > > > LOSS OF USE, > > > > > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER > > CAUSED > > > > AND ON ANY > > > > > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, > > OR > > > > TORT > > > > > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > > OUT > > > > OF THE USE > > > > > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUC= H > > > > DAMAGE. > > > > > + */ > > > > > + > > > > > +#ifndef _RTE_ETH_DEV_INFO_H_ > > > > > +#define _RTE_ETH_DEV_INFO_H_ > > > > > + > > > > > + > > > > > +/* > > > > > + * Placeholder for accessing device registers */ struct > > > > > +rte_dev_reg_info { > > > > > + void *buf; /**< Buffer for register */ > > > > > + uint32_t offset; /**< Offset for 1st register to fetch */ > > > > > + uint32_t leng; /**< Number of registers to fetch */ > > > > > + uint32_t version; /**< Device version */ }; > > > > > + > > > > > +/* > > > > > + * Placeholder for accessing device eeprom */ struct > > > > > +rte_dev_eeprom_info { > > > > > + void *buf; /**< Buffer for eeprom */ > > > > > + uint32_t offset; /**< Offset for 1st eeprom location to access = */ > > > > > + uint32_t leng; /**< Length of eeprom region to access */ > > > > > + uint32_t magic; /**< Device ID */ }; > > > > > + > > > > > +/* > > > > > + * Placeholder for accessing device ring parameters */ struct > > > > > +rte_dev_ring_info { > > > > > + uint32_t rx_pending; /**< Number of outstanding Rx ring */ > > > > > + uint32_t tx_pending; /**< Number of outstanding Tx ring */ > > > > > + uint32_t rx_max_pending; /**< Maximum number of outstanding Rx > > > > ring */ > > > > > + uint32_t tx_max_pending; /**< Maximum number of outstanding Tx > > > > ring > > > > > +*/ }; > > > > > + > > > > > +/* > > > > > + * A data structure captures information as defined in struct > > > > > +ifla_vf_info > > > > > + * for user-space api > > > > > + */ > > > > > +struct rte_dev_vf_info { > > > > > + uint32_t vf; > > > > > + uint8_t mac[ETHER_ADDR_LEN]; > > > > > + uint32_t vlan; > > > > > + uint32_t tx_rate; > > > > > + uint32_t spoofchk; > > > > > +}; > > > > > > > > > > > > Wonder what that structure is for? > > > > I can't see it used in any function below? > > > > > > > > > > Good catch, this is designed for other ethtool ops that I did not inc= lude in > > this release, I will remove this from next fix. > > > > > > > > + > > > > > +#endif /* _RTE_ETH_DEV_INFO_H_ */ > > > > > diff --git a/lib/librte_ether/rte_ethdev.c > > > > > b/lib/librte_ether/rte_ethdev.c index 5a94654..186e85c 100644 > > > > > --- a/lib/librte_ether/rte_ethdev.c > > > > > +++ b/lib/librte_ether/rte_ethdev.c > > > > > @@ -2751,6 +2751,32 @@ rte_eth_dev_mac_addr_remove(uint8_t > > > > port_id, > > > > > struct ether_addr *addr) } > > > > > > > > > > int > > > > > +rte_eth_dev_default_mac_addr_set(uint8_t port_id, struct > > > > > +ether_addr > > > > > +*addr) { > > > > > + struct rte_eth_dev *dev; > > > > > + const int index =3D 0; > > > > > + const uint32_t pool =3D 0; > > > > > + > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", port_id); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + dev =3D &rte_eth_devices[port_id]; > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mac_addr_remove, - > > > > ENOTSUP); > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mac_addr_add, - > > > > ENOTSUP); > > > > > + > > > > > + /* Update NIC default MAC address*/ > > > > > + (*dev->dev_ops->mac_addr_remove)(dev, index); > > > > > + (*dev->dev_ops->mac_addr_add)(dev, addr, index, pool); > > > > > + > > > > > + /* Update default address in NIC data structure */ > > > > > + ether_addr_copy(addr, &dev->data->mac_addrs[index]); > > > > > + > > > > > + return 0; > > > > > +} > > > > > + > > > > > +int > > > > > rte_eth_dev_set_vf_rxmode(uint8_t port_id, uint16_t vf, > > > > > uint16_t rx_mode, uint8_t on) { @@ -3627,3 > > +3653,136 @@ > > > > > rte_eth_remove_tx_callback(uint8_t port_id, > > > > uint16_t queue_id, > > > > > /* Callback wasn't found. */ > > > > > return -EINVAL; > > > > > } > > > > > + > > > > > +int > > > > > +rte_eth_dev_reg_leng(uint8_t port_id) { > > > > > + struct rte_eth_dev *dev; > > > > > + > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", port_id); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_reg_length, - > > > > ENOTSUP); > > > > > + return (*dev->dev_ops->get_reg_length)(dev); > > > > > +} > > > > > + > > > > > +int > > > > > +rte_eth_dev_reg_info(uint8_t port_id, struct rte_dev_reg_info > > > > > +*info) { > > > > > + struct rte_eth_dev *dev; > > > > > + > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", port_id); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_reg, -ENOTSUP); > > > > > + return (*dev->dev_ops->get_reg)(dev, info); } > > > > > > > > Seems that *get_reg* stuff, will be really good addition for DPDK > > > > debugging abilities. > > > > Though, I'd suggest we change it a bit to make more generic and fle= xible: > > > > > > > > Introduce rte_eth_reg_read/rte_eth_reg_write(), > > > > or probably even better rte_pcidev_reg_read /rte_pcidev_reg_write a= t > > EAL. > > > > Something similar to what port_pci_reg_read/port_pci_reg_write() ar= e > > > > doing now at testpmd.h. > > > > > > > > struct rte_pcidev_reg_info { > > > > const char *name; > > > > uint32_t endianes, bar, offset, size, count; }; > > > > > > > > int rte_pcidev_reg_read(const struct rte_pci_device *, const struct > > > > rte_pcidev_reg_info *, uint64_t *reg_val); > > > > > > > > Then: > > > > int rte_eth_dev_get_reg_info(port_id, const struct > > > > rte_pcidev_reg_info **info); > > > > > > > > So each device would store in info a pointer to an array of it's > > > > register descriptions (finished by zero elem?). > > > > > > > > Then your ethtool (or any other upper layer) can do the following t= o > > > > read all device regs: > > > > > > > > > > The proposed reg info structure allows future improvement to support > > individual register read/write. > > > Also, because each NIC device has a very distinguish register definit= ion. > > > So, the plan is to have more comprehensive interface to support query > > > operation (for example, register name) before introduce individual/gr= oup > > register access. > > > Points taken, the support will be in future release. > > > > Sorry, didn't get you. > > So you are ok to make these changes in next patch version? > > > I would like to get a consensus from dpdk community on how to provide reg= ister information. Well, that' ok, but if it is just a trial patch that is not intended to be = applied, then you should mark it as RFC. > Currently, it's designed for debug dumping. The register information is v= ery hardware dependent. > Need to consider current supported NIC device and future devices for DPDK= , so we won't make it a bulky interface. Ok, could you explain what exactly concerns you in the approach described = above? What part you feel is bulky? > > > > > > > const struct rte_eth_dev_reg_info *reg_info; struct rte_eth_dev_inf= o > > > > dev_info; > > > > > > > > rte_eth_dev_info_get(pid, &dev_info); > > > > rte_eth_dev_get_reg_info(port_id, ®_info); > > > > > > > > for (i =3D 0; reg_info[i].name !=3D NULL; i++) { > > > > ... > > > > rte_pcidev_read_reg(dev_info. pci_dev, reg_info[i], &v); > > > > .. > > > > } > > > > > > > > > + > > > > > +int > > > > > +rte_eth_dev_eeprom_leng(uint8_t port_id) { > > > > > + struct rte_eth_dev *dev; > > > > > + > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", port_id); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_eeprom_length, - > > > > ENOTSUP); > > > > > + return (*dev->dev_ops->get_eeprom_length)(dev); > > > > > +} > > > > > + > > > > > +int > > > > > +rte_eth_dev_get_eeprom(uint8_t port_id, struct > > > > > +rte_dev_eeprom_info > > > > > +*info) { > > > > > + struct rte_eth_dev *dev; > > > > > + > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", port_id); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_eeprom, - > > > > ENOTSUP); > > > > > + return (*dev->dev_ops->get_eeprom)(dev, info); } > > > > > + > > > > > +int > > > > > +rte_eth_dev_set_eeprom(uint8_t port_id, struct > > > > > +rte_dev_eeprom_info > > > > > +*info) { > > > > > + struct rte_eth_dev *dev; > > > > > + > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", port_id); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_eeprom, - > > > > ENOTSUP); > > > > > + return (*dev->dev_ops->set_eeprom)(dev, info); } > > > > > + > > > > > +int > > > > > +rte_eth_dev_get_ringparam(uint8_t port_id, struct > > > > > +rte_dev_ring_info > > > > > +*info) { > > > > > + struct rte_eth_dev *dev; > > > > > + > > > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", port_id); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + if ((dev=3D &rte_eth_devices[port_id]) =3D=3D NULL) { > > > > > + PMD_DEBUG_TRACE("Invalid port device\n"); > > > > > + return -ENODEV; > > > > > + } > > > > > + > > > > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_ringparam, - > > > > ENOTSUP); > > > > > + return (*dev->dev_ops->get_ringparam)(dev, info); } > > > > > > > > I think it will be a useful addition to the ethdev API to have an > > > > ability to retrieve current RX/TX queue parameters. > > > > Though again, it need to be more generic, so it could be useful for > > > > non- ethtool upper layer too. > > > > So I suggest to modify it a bit. > > > > Something like that: > > > > > > > > struct rte_eth_tx_queue_info { > > > > struct rte_eth_txconf txconf; > > > > uint32_t nb_tx_desc; > > > > uint32_t nb_max_tx_desc; /*max allowable TXDs for that queue */ > > > > uint32_t nb_tx_free; /* number of free TXDs at the m= oment of > > call. > > > > */ > > > > /* other tx queue data. */ > > > > }; > > > > > > > > int rte_etdev_get_tx_queue_info(portid, queue_id, struct > > > > rte_eth_tx_queue_info *qinfo) > > > > > > > > Then, your upper layer ethtool wrapper, can implement yours > > > > ethtool_get_ringparam() by: > > > > > > > > ... > > > > struct rte_eth_tx_queue_info qinfo; > > > > rte_ethdev_get_tx_queue_info(port, 0, &qinfo); > > > > ring_param->tx_pending =3D qinfo.nb_tx_desc - > > > > rte_eth_rx_queue_count(port, 0); > > > > > > > > Or probably even: > > > > ring_param->tx_pending =3D qinfo.nb_tx_desc - qinfo.nb_tx_free; > > > > > > > > Same for RX. > > > > > > > For now, this descriptor ring information is used by the ethtool op. > > > To make this interface simple, i.e. caller doesn't need to access oth= er > > queue information. > > > > I just repeat what I said to you in off-line conversation: > > ethdev API is not equal ethtool API. > > It is ok to add a new function/structure to ethdev if it really needed= , but we > > should do mechanical one to one copy. > > It is much better to add a function/structure that would be more gener= ic, > > and suit other users, not only ethtool. > > There is no point to have dozen functions in rte_ethdev API providing s= imilar > > information. > > BTW, I don't see how API I proposed is much more complex, then yours o= ne. > The ring parameter is a run-time information which is different than data= structure described in this discussion. I don't see how they are different. Looking at ixgbe_get_ringparam(), it returns: rx_max_pending - that's a static IXGBE PMD value (max possible number of RX= Ds per one queue). rx_pending - number of RXD currently in use by the HW for queue 0 (that inf= ormation can be changed at each call). With the approach I suggesting - you can get same information for each RX q= ueue by calling rte_ethdev_get_rx_queue_info() and rte_eth_rx_queue_count().=20 Plus you are getting other RX queue data. Another thing - what is practical usage of the information you retrieving n= ow by get_ringparam()? Let say it returned to you: rx_max_pending=3D4096; rx_pending=3D128; How that information would help to understand what is going on with the dev= ice? Without knowing value of nb_tx_desc for the queue, you can't say is you qu= eue full or not. Again, it could be that all your traffic going through some other queue (no= t 0). So from my point rte_eth_dev_get_ringparam() usage is very limited, and do= esn't provide enough information about current queue state. Same thing applies for TX.=20 > It's the desire of this patch to separate each data structure to avoid cr= oss dependency. That's too cryptic to me. Could you explain what cross dependency you are talking about? Konstantin