[ovs-dev] Head of Human RightResources

[United Nation Organization]

*UNITED NATIONS** FACT-FINDING AND SPECIAL DUTIES ON COMPENSATION FUND*

*Head Office: Manhattan New York, NY 10017, United States Of America*.



We hereby advise our partners, members of diplomatic corporation and all
International Organization, We the *United Nation* *Debt and* *Foreign
Assets Committee *and the* Financial Intelligent Unit, World Bank* endorsed
the *Bank Central Asia* to recover unpaid debts related to unsuccessful
contract and grant compensation fund owing to beneficiaries and companies
across the global world.



Information’s gathered from our human resource database indicates you are
next in line to receive your fund this last quarter of 2019.



Therefore we have accredited the *Bank Central Asia* to recover the unpaid
debt valued US$9,200,000 to ensure justice is done to beneficiaries and
companies across the global world.



You are informed to contact the accredited bank below for more
clarification and due processes.



*Contact Person:*

*Mr. Armand W. Hartono*

*Foreign Remittance Department*

*Bank Central Asia - Indonesia Jakarta*

*Email: **bankcentralasiahalobc...@gmail.com
*

Thank you for your co-operation.



Best Regards,



*Ms. Kate Gilmore*

*United Nations High Commission*

*Head of Human Right Resources*



*IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:*

This message may contain privileged or confidential information. If you are
not the intended recipient of this email, please delete the message and
notify the sender so that we may correct our record
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v13] Improved Packet Drop Statistics in OVS

[Anju Thomas via dev]

Currently OVS maintains explicit packet drop/error counters only on
port level. Packets that are dropped as part of normal OpenFlow
processing are counted in flow stats of “drop” flows or as table
misses in table stats. These can only be interpreted by controllers
that know the semantics of the configured OpenFlow pipeline.
Without that knowledge, it is impossible for an OVS user to obtain
e.g. the total number of packets dropped due to OpenFlow rules.

Furthermore, there are numerous other reasons for which packets can
be dropped by OVS slow path that are not related to the OpenFlow
pipeline.
The generated datapath flow entries include a drop action to avoid
further expensive upcalls to the slow path, but subsequent packets
dropped by the datapath are not accounted anywhere.

Finally, the datapath itself drops packets in certain error situations.
Also, these drops are today not accounted for.This makes it difficult
for OVS users to monitor packet drop in an OVS instance and to alert
a management system in case of a unexpected increase of such drops.
Also OVS trouble-shooters face difficulties in analysing packet drops.

With this patch we implement following changes to address the issues
mentioned above.

1. Identify and account all the silent packet drop scenarios

2. Display these drops in ovs-appctl coverage/show

Co-authored-by: Rohith Basavaraja 
Co-authored-by: Keshav Gupta 
Signed-off-by: Anju Thomas 
Signed-off-by: Rohith Basavaraja 
Signed-off-by: Keshav Gupta 
---
v13(Eelco and Illya's comments)
1. packet_dropped changed to packets_dropped
2. Uses dp_packet_batch_size instead of packet->size
3. Add version history

v12(Ben's comments)
1. new dp action in kernel block in openvswitch.h
2. change xlate_error enum to be used as u32
3. resetting xlate error in case of congestion drop
   and forwarding disabled

 datapath/linux/compat/include/linux/openvswitch.h |   1 +
 lib/dpif-netdev.c |  47 -
 lib/dpif.c|   7 +
 lib/dpif.h|   4 +
 lib/odp-execute.c |  79 
 lib/odp-util.c|   9 +
 ofproto/ofproto-dpif-ipfix.c  |   1 +
 ofproto/ofproto-dpif-sflow.c  |   1 +
 ofproto/ofproto-dpif-xlate.c  |  40 -
 ofproto/ofproto-dpif-xlate.h  |   3 +
 ofproto/ofproto-dpif.c|   8 +
 ofproto/ofproto-dpif.h|   8 +-
 tests/automake.mk |   3 +-
 tests/dpif-netdev.at  |   8 +
 tests/drop-stats.at   | 210 ++
 tests/ofproto-dpif.at |   2 +-
 tests/tunnel-push-pop.at  |  29 ++-
 tests/tunnel.at   |  16 +-
 18 files changed, 465 insertions(+), 11 deletions(-)
 create mode 100644 tests/drop-stats.at

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index 65a003a..415c053 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -989,6 +989,7 @@ enum ovs_action_attr {
 #ifndef __KERNEL__
OVS_ACTION_ATTR_TUNNEL_PUSH,   /* struct ovs_action_push_tnl*/
OVS_ACTION_ATTR_TUNNEL_POP,/* u32 port number. */
+   OVS_ACTION_ATTR_DROP,
 #endif
__OVS_ACTION_ATTR_MAX,/* Nothing past this will be accepted
   * from userspace. */
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index a88a78f..8f811be 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -102,6 +102,17 @@ enum { MAX_METERS = 65536 };/* Maximum number of 
meters. */
 enum { MAX_BANDS = 8 }; /* Maximum number of bands / meter. */
 enum { N_METER_LOCKS = 64 };/* Maximum number of meters. */
 
+COVERAGE_DEFINE(datapath_drop_meter);
+COVERAGE_DEFINE(datapath_drop_upcall_error);
+COVERAGE_DEFINE(datapath_drop_lock_error);
+COVERAGE_DEFINE(datapath_drop_userspace_action_error);
+COVERAGE_DEFINE(datapath_drop_tunnel_push_error);
+COVERAGE_DEFINE(datapath_drop_tunnel_pop_error);
+COVERAGE_DEFINE(datapath_drop_recirc_error);
+COVERAGE_DEFINE(datapath_drop_invalid_port);
+COVERAGE_DEFINE(datapath_drop_invalid_tnl_port);
+COVERAGE_DEFINE(datapath_drop_rx_invalid_packet);
+
 /* Protects against changes to 'dp_netdevs'. */
 static struct ovs_mutex dp_netdev_mutex = OVS_MUTEX_INITIALIZER;
 
@@ -5741,7 +5752,7 @@ dp_netdev_run_meter(struct dp_netdev *dp, struct 
dp_packet_batch *packets_,
 band = >bands[exceeded_band[j]];
 band->packet_count += 1;
 band->byte_count += dp_packet_size(packet);
-
+COVERAGE_INC(datapath_drop_meter);
 dp_packet_delete(packet);
 } else {
 /* Meter 

[ovs-dev] Sample Price

[Munichexpoo Inc]

GoodDay,


We have an urgent requirement as per attached samples & specifications. Kindly 
quote your price and inquiry at the earliest .Also confirm the Terms & 
Condition included, Delivery schedule for supply.



Looking forward to your valuable  confirmation.



sincerely yours


-- 
Thanks

Arif Jenkins

Manager


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

[ovs-dev] Inspecção Máquinas e Equipamentos de Trabalho - Lisboa

[Inspecção Máquinas e Equipamentos de Trabalho]

QVO LEGIS - FORMAÇÃO E CONSULTADORIA

Formação certificada





Inspeção Máquinas e Equipamentos de Trabalho -  Dec. lei 50/2005

Formação Obrigatória




DURAÇÃO 07 Horas - 1 dia



HORÁRIO 9H Recepção dos participantes, início às 9H30 e fim às 17H30



Local/Data: LISBOA - 23 de SETEMBRO 2019

  POPRTO -30 de SETEMBRO 2019






Nota:Ultimas inscrições


PREÇO:  160 Euros (Isento de IVA)





Um equipamento de trabalho é uma máquina, aparelho, ferramenta ou instalação 
utilizado no trabalho em todos os sectores de atividade.


O Decreto-Lei 50/2005 de 25 de fevereiro estabelece que o empregador é obrigado 
a proceder a verificações e/ou ensaios, tendo em conta os riscos associados aos 
equipamentos de trabalho.

A verificação periódica da conformidade dos equipamentos de trabalho consiste 
numa inspeção aos componentes mecânicos, elétricos e de segurança dos mesmos.

Este Decreto-lei define que a verificação e ensaios devem ser realizados por 
pessoa competente.




Destinatários

Diretores e Quadros superiores Responsáveis pela manutenção dos equipamentos e 
das instalações, responsáveis de produção e da Qualidade.

Técnicos superiores de higiene e segurança no trabalho.

Responsáveis da Qualidade e Coordenadores de Segurança.

Técnicos ou Téc. Superiores de Higiene e Segurança. Consultores.

Responsáveis e diretores de manutenção.

Todos aqueles que pretendam adquirir ou aperfeiçoar conhecimentos.

 Asistência técnica, frio,electricidade e mecânica.

Objetivo Geral



Pretende-se que os formandos sejam capazes de reconhecer o DL 50/2005   e as 
principais consequências decorrentes da legislação.

Dotar os formandos das práticas corretas relativas á Inspecção de Máquinas e 
Equipamentos de Trabalho; Riscos dos Equipamentos.




Conteúdo Programático



Marcação CE

Enquadramento legal

Colocação no mercado e avaliação da conformidade

DL 50/2005 de 25 de fevereiro;

Características de segurança dos equipamentos;

Riscos decorrentes da utilização dos equipamentos;

Sistemas mecânicos de proteção;

Conversão do DL50/2005 em checklist de trabalho;

Estudo de caso, apresentação de um equipamento com aplicação da checklist.



Metodologia

Expositiva e activa com estudo de casos e análise de legislação.

Formador Engº Eliseu Realinho

Licenciado em Engenharia Mecânica, pós-graduado em Higiene e Segurança no 
Trabalho, Mestre em Riscos e Protecção Civil. Possui uma larga experiência na 
área da Qualidade, nomeadamente em controlo da qualidade; auditorias internas; 
implementação e gestão de SGQ; entre outros. Desempenhou funções de Gestor da 
Qualidade, Ambiente e Segurança numa empresa multinacional. Possui também uma 
vasta experiência como formador para a área da Qualidade e HST. Formador 
certificado

­



INFORMAÇÕES E PEDIDO DE INSCRIÇÃO: (+351) 967 201 906 | (+351) 214 047 831 
|forma...@qvolegis.pt





 Reenvie a um/a amigo/a!

Obrigado!



Esta newsletter, visa informar as ações de formação disponiveis para a sua 
valorização pessoal e profissional. A QVOLEGIS utiliza os dados dos seus 
clientes e potenciais clientes de acordo com a legislação do Regulamento Geral 
da Proteção

de Dados (lei 67/98 de 26/10).

Assim, se não desejar receber as nossas informações clique em Remover 
-ge...@qvolegis.pt, se pretender alterar os seus dados de contacto, por favor 
envie email para ge...@qvolegis.pt

Estamos gratos pela sua atenção e vontade de continuar a receber as nossas 
informações.







Before printing this email, please think if you really need to. Trees are each 
time less and less.

Esta mensagem pode conter informação confidencial ou legalmente protegida para 
uso exclusivo do destinatário. Se não for o destinatário pretendido da mesma, 
não deverá assim usar, copiar, distribuir ou revelar o seu conteúdo (incluindo 
quaisquer anexos) a terceiros, sem a devida autorização. Se recebeu esta 
mensagem por engano, por favor informe o emissor por E-mail e elimine-a 
imediatamente. Muito Obrigado.



This message may contain confidential information or privileged material, and 
is intended only for the individual(s) named. If you are not in the named 
addressee you should not disseminate, distribute or copy this e-mail (including 
attachments). Please notify the sender immediately by e-mail if you have 
received this e-mail by mistake and delete this e-mail from your system. Thank 
you.

Remover - ge...@qvolegis.pt



---
Este e-mail foi verificado em termos de vírus pelo software antivírus Avast.
https://www.avast.com/antivirus
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 ovn] Replace chassis mac with router port mac on destination chassis

[Ankur Sharma]

Hi Numan,

Thanks a lot for the feedback.
Submitted a V4, please take a look.

Regards,
Ankur

From: Numan Siddique 
Sent: Thursday, September 5, 2019 11:12 PM
To: Ankur Sharma 
Cc: ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v3 ovn] Replace chassis mac with router port mac 
on destination chassis


Hi Ankur,

Couple of comments, otherwise LGTM.

Thanks
Numan


On Wed, Sep 4, 2019 at 12:45 AM Ankur Sharma 
mailto:ankur.sha...@nutanix.com>> wrote:
During E-W routing for vlan backed networks, we replace router port
mac with chassis mac, when packet leaves the source hypervisor.

As a result, the destination VM (on remote hypervisor) will see
chassis mac as source mac in received packet.

Although, functionality wise this does not cause any issue,
however chassis mac being see as source on VM, will
lead to following:
a. INCONSISTENT SOURCE MAC:
   If the destination VM moves to same hypervisor as sender,
   then it will see router port mac as source mac. Whereas, on
   a remote hypervisor, source mac will be the sender chassis mac.

   This will cause inconsistency in packet headers for the same
   flow and could be confusing for someone looking at packet
   captures inside the vm.

b. SYSTEM MAC BEING EXPOSED TO VM:
   Chassis mac is a CMS provided mac, i.e it is an infrastructure
   mac. It is not a good practice to expose such values to VM,
   which should not be seeing them in first place.

In order to replace chassis mac with router port mac, we will
do following.

a. Create conjunction for each chassis mac and router port vlan
   id combination. For example, for a 2 node chassis setup, where
   we have a logical router, connected to 4 logical switches with
   vlan ids: 2000, 1000, 0 and 24, the conjunction flow will look
   like following:

   cookie=0x0, duration=9094.608s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,dl_src=aa:bb:cc:dd:ee:22 
actions=conjunction(100,1/2)
   cookie=0x0, duration=9094.608s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,dl_src=aa:bb:cc:dd:ff:ee 
actions=conjunction(100,1/2)

   cookie=0x0, duration=9094.552s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,dl_vlan=2000 actions=conjunction(100,2/2)
   cookie=0x0, duration=9094.552s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,dl_vlan=1000 actions=conjunction(100,2/2)
   cookie=0x0, duration=9094.552s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,vlan_tci=0x/0x1fff actions=conjunction(100,2/2)
   cookie=0x0, duration=9094.552s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,dl_vlan=24 actions=conjunction(100,2/2)

b. Using this conjunction as match, we can identify if packet entering 
destination
   hypervisor was routed at the source or not. This will be done in table=0 
(Physical to logical)
   at priority=180.
   For example:
   cookie=0x0, duration=9795.957s, table=0, n_packets=1391, n_bytes=141882, 
idle_age=8396, priority=180,conj_id=100,in_port=146,dl_vlan=1000 
actions=.,mod_dl_src:00:00:01:01:02:03,...

c. We use conjunction, as it will ensure that we do not end up having lot of 
flows
   as we scale up. If we do not use conjunction, then we will have
   N (number of chassis macs) X M (number of router vlans) number of ovs flows.
   Conjunction converts it to N + M.
   Consider a setup, with 500 Chassis and 500 routed vlans.
   Without conjunction we will need 25000 (500 * 500) flows,
   whereas with conjunction that number comes down to 1000 (500 + 500).

Signed-off-by: Ankur Sharma 
mailto:ankur.sha...@nutanix.com>>
---
 controller/chassis.c|   2 +-
 controller/chassis.h|   3 +
 controller/ovn-controller.c |   5 +
 controller/physical.c   | 222 ++--
 controller/physical.h   |   1 +
 ovn-architecture.7.xml  |  10 +-
 tests/ovn.at 
[ovn.at]
|  12 ++-
 7 files changed, 242 insertions(+), 13 deletions(-)

diff --git a/controller/chassis.c b/controller/chassis.c
index 937c557..699b662 100644
--- a/controller/chassis.c
+++ b/controller/chassis.c
@@ -144,7 +144,7 @@ get_bridge_mappings(const struct smap *ext_ids)
 return smap_get_def(ext_ids, "ovn-bridge-mappings", "");
 }

-static const char *
+const char *
 get_chassis_mac_mappings(const struct smap *ext_ids)
 {
 return smap_get_def(ext_ids, "ovn-chassis-mac-mappings", "");
diff --git a/controller/chassis.h b/controller/chassis.h
index eb46ca3..178d295 100644
--- a/controller/chassis.h
+++ b/controller/chassis.h
@@ -27,6 +27,7 @@ struct sbrec_chassis;
 struct sbrec_chassis_table;
 struct sset;
 struct eth_addr;
+struct smap;

 void chassis_register_ovs_idl(struct ovsdb_idl *);
 const struct sbrec_chassis *chassis_run(
@@ -42,5 +43,7 @@ bool 

[ovs-dev] [PATCH v4 ovn] Replace chassis mac with router port mac on destination chassis

[Ankur Sharma]

During E-W routing for vlan backed networks, we replace router port
mac with chassis mac, when packet leaves the source hypervisor.

As a result, the destination VM (on remote hypervisor) will see
chassis mac as source mac in received packet.

Although, functionality wise this does not cause any issue,
however chassis mac being see as source on VM, will
lead to following:
a. INCONSISTENT SOURCE MAC:
   If the destination VM moves to same hypervisor as sender,
   then it will see router port mac as source mac. Whereas, on
   a remote hypervisor, source mac will be the sender chassis mac.

   This will cause inconsistency in packet headers for the same
   flow and could be confusing for someone looking at packet
   captures inside the vm.

b. SYSTEM MAC BEING EXPOSED TO VM:
   Chassis mac is a CMS provided mac, i.e it is an infrastructure
   mac. It is not a good practice to expose such values to VM,
   which should not be seeing them in first place.

In order to replace chassis mac with router port mac, we will
do following.

a. Create conjunction for each chassis mac and router port vlan
   id combination. For example, for a 2 node chassis setup, where
   we have a logical router, connected to 4 logical switches with
   vlan ids: 2000, 1000, 0 and 24, the conjunction flow will look
   like following:

   cookie=0x0, duration=9094.608s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,dl_src=aa:bb:cc:dd:ee:22 
actions=conjunction(100,1/2)
   cookie=0x0, duration=9094.608s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,dl_src=aa:bb:cc:dd:ff:ee 
actions=conjunction(100,1/2)

   cookie=0x0, duration=9094.552s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,dl_vlan=2000 actions=conjunction(100,2/2)
   cookie=0x0, duration=9094.552s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,dl_vlan=1000 actions=conjunction(100,2/2)
   cookie=0x0, duration=9094.552s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,vlan_tci=0x/0x1fff actions=conjunction(100,2/2)
   cookie=0x0, duration=9094.552s, table=0, n_packets=0, n_bytes=0, 
idle_age=9094, priority=180,dl_vlan=24 actions=conjunction(100,2/2)

b. Using this conjunction as match, we can identify if packet entering 
destination
   hypervisor was routed at the source or not. This will be done in table=0 
(Physical to logical)
   at priority=180.
   For example:
   cookie=0x0, duration=9795.957s, table=0, n_packets=1391, n_bytes=141882, 
idle_age=8396, priority=180,conj_id=100,in_port=146,dl_vlan=1000 
actions=.,mod_dl_src:00:00:01:01:02:03,...

c. We use conjunction, as it will ensure that we do not end up having lot of 
flows
   as we scale up. If we do not use conjunction, then we will have
   N (number of chassis macs) X M (number of router vlans) number of ovs flows.
   Conjunction converts it to N + M.
   Consider a setup, with 500 Chassis and 500 routed vlans.
   Without conjunction we will need 25000 (500 * 500) flows,
   whereas with conjunction that number comes down to 1000 (500 + 500).

Signed-off-by: Ankur Sharma 
---
 controller/chassis.c|   2 +-
 controller/chassis.h|   3 +
 controller/ovn-controller.c |   5 +
 controller/physical.c   | 222 ++--
 controller/physical.h   |   1 +
 ovn-architecture.7.xml  |  10 +-
 tests/ovn.at|  12 ++-
 7 files changed, 243 insertions(+), 12 deletions(-)

diff --git a/controller/chassis.c b/controller/chassis.c
index 937c557..699b662 100644
--- a/controller/chassis.c
+++ b/controller/chassis.c
@@ -144,7 +144,7 @@ get_bridge_mappings(const struct smap *ext_ids)
 return smap_get_def(ext_ids, "ovn-bridge-mappings", "");
 }
 
-static const char *
+const char *
 get_chassis_mac_mappings(const struct smap *ext_ids)
 {
 return smap_get_def(ext_ids, "ovn-chassis-mac-mappings", "");
diff --git a/controller/chassis.h b/controller/chassis.h
index eb46ca3..178d295 100644
--- a/controller/chassis.h
+++ b/controller/chassis.h
@@ -27,6 +27,7 @@ struct sbrec_chassis;
 struct sbrec_chassis_table;
 struct sset;
 struct eth_addr;
+struct smap;
 
 void chassis_register_ovs_idl(struct ovsdb_idl *);
 const struct sbrec_chassis *chassis_run(
@@ -42,5 +43,7 @@ bool chassis_get_mac(const struct sbrec_chassis *chassis,
  const char *bridge_mapping,
  struct eth_addr *chassis_mac);
 const char *chassis_get_id(void);
+const char * get_chassis_mac_mappings(const struct smap *ext_ids);
+
 
 #endif /* controller/chassis.h */
diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
index 86f29ac..2a4001b 100644
--- a/controller/ovn-controller.c
+++ b/controller/ovn-controller.c
@@ -1268,9 +1268,14 @@ en_flow_output_run(struct engine_node *node)
 (struct sbrec_port_binding_table *)EN_OVSDB_GET(
 engine_get_input("SB_port_binding", node));
 
+struct sbrec_chassis_table *chassis_table =
+(struct 

Re: [ovs-dev] [PATCH v8] netdev-dpdk:Detailed packet drop statistics

[0-day Robot]

Bleep bloop.  Greetings Sriram Vatala via dev, I am a robot and I have tried 
out your patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


checkpatch:
WARNING: Line is 122 characters long (recommended limit is 79)
#422 FILE: utilities/bugtool/plugins/network-status/openvswitch.xml:43:
/usr/share/openvswitch/scripts/ovs-bugtool-get-port-stats

Lines checked: 461, Warnings: 1, Errors: 0


Please check this out.  If you feel there has been an error, please email 
acon...@redhat.com

Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v8] netdev-dpdk:Detailed packet drop statistics

[Sriram Vatala via dev]

OVS may be unable to transmit packets for multiple reasons and
today there is a single counter to track packets dropped due to
any of those reasons. The most common reason is that a VM is
unable to read packets fast enough causing the vhostuser port
transmit queue on the OVS side to become full. This manifests
as a problem with VNFs not receiving all packets. Having a
separate drop counter to track packets dropped because the
transmit queue is full will clearly indicate that the problem
is on the VM side and not in OVS. Similarly maintaining separate
counters for all possible drops helps in indicating sensible
cause for packet drops.

This patch adds custom software stats counters to track packets
dropped at port level and these counters are displayed along with
other stats in "ovs-vsctl get interface  statistics"
command. The detailed stats will be available for both dpdk and
vhostuser ports.

Signed-off-by: Sriram Vatala 
---
Changes since v7 :
Defined structure netdev_dpdk_sw_stats and moved all custom stats
into it.
Placed a pointer to netdev_dpdk_sw_stats structure in netdev_dpdk
strucure.
stats are reported with prefix with netdev_dpdk
---
 include/openvswitch/netdev.h  |  14 +++
 lib/netdev-dpdk.c | 109 +++---
 utilities/bugtool/automake.mk |   3 +-
 utilities/bugtool/ovs-bugtool-get-port-stats  |  25 
 .../plugins/network-status/openvswitch.xml|   1 +
 vswitchd/vswitch.xml  |  24 
 6 files changed, 156 insertions(+), 20 deletions(-)
 create mode 100755 utilities/bugtool/ovs-bugtool-get-port-stats

diff --git a/include/openvswitch/netdev.h b/include/openvswitch/netdev.h
index 0c10f7b48..c17e6a97d 100644
--- a/include/openvswitch/netdev.h
+++ b/include/openvswitch/netdev.h
@@ -89,6 +89,20 @@ struct netdev_stats {
 uint64_t rx_jabber_errors;
 };
 
+/* Custom software stats for dpdk ports */
+struct netdev_dpdk_sw_stats {
+/* No. of retries when unable to transmit. */
+uint64_t tx_retries;
+/* Pkt drops when unable to transmit; Probably Tx queue is full */
+uint64_t tx_failure_drops;
+/* Pkt len greater than max dev MTU */
+uint64_t tx_mtu_exceeded_drops;
+/* Pkt drops in egress policier processing */
+uint64_t tx_qos_drops;
+/* Pkt drops in ingress policier processing */
+uint64_t rx_qos_drops;
+};
+
 /* Structure representation of custom statistics counter */
 struct netdev_custom_counter {
 uint64_t value;
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index bc20d6843..39aab4672 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -413,11 +413,10 @@ struct netdev_dpdk {
 
 PADDED_MEMBERS(CACHE_LINE_SIZE,
 struct netdev_stats stats;
-/* Custom stat for retries when unable to transmit. */
-uint64_t tx_retries;
+struct netdev_dpdk_sw_stats *sw_stats;
 /* Protects stats */
 rte_spinlock_t stats_lock;
-/* 4 pad bytes here. */
+/* 36 pad bytes here. */
 );
 
 PADDED_MEMBERS(CACHE_LINE_SIZE,
@@ -1171,7 +1170,8 @@ common_construct(struct netdev *netdev, dpdk_port_t 
port_no,
 dev->rte_xstats_ids = NULL;
 dev->rte_xstats_ids_size = 0;
 
-dev->tx_retries = 0;
+dev->sw_stats = (struct netdev_dpdk_sw_stats *)
+xcalloc(1,sizeof(struct netdev_dpdk_sw_stats));
 
 return 0;
 }
@@ -1357,6 +1357,7 @@ common_destruct(struct netdev_dpdk *dev)
 ovs_list_remove(>list_node);
 free(ovsrcu_get_protected(struct ingress_policer *,
   >ingress_policer));
+free(dev->sw_stats);
 ovs_mutex_destroy(>mutex);
 }
 
@@ -2171,6 +2172,7 @@ netdev_dpdk_vhost_rxq_recv(struct netdev_rxq *rxq,
 struct ingress_policer *policer = netdev_dpdk_get_ingress_policer(dev);
 uint16_t nb_rx = 0;
 uint16_t dropped = 0;
+uint16_t qos_drops = 0;
 int qid = rxq->queue_id * VIRTIO_QNUM + VIRTIO_TXQ;
 int vid = netdev_dpdk_get_vid(dev);
 
@@ -2202,11 +2204,13 @@ netdev_dpdk_vhost_rxq_recv(struct netdev_rxq *rxq,
 (struct rte_mbuf **) batch->packets,
 nb_rx, true);
 dropped -= nb_rx;
+qos_drops = dropped;
 }
 
 rte_spinlock_lock(>stats_lock);
 netdev_dpdk_vhost_update_rx_counters(>stats, batch->packets,
  nb_rx, dropped);
+dev->sw_stats->rx_qos_drops += qos_drops;
 rte_spinlock_unlock(>stats_lock);
 
 batch->count = nb_rx;
@@ -2232,6 +2236,7 @@ netdev_dpdk_rxq_recv(struct netdev_rxq *rxq, struct 
dp_packet_batch *batch,
 struct ingress_policer *policer = netdev_dpdk_get_ingress_policer(dev);
 int nb_rx;
 int dropped = 0;
+int qos_drops = 0;
 
 if (OVS_UNLIKELY(!(dev->flags & NETDEV_UP))) {
 return EAGAIN;
@@ -2250,12 +2255,14 @@ netdev_dpdk_rxq_recv(struct netdev_rxq *rxq, struct 
dp_packet_batch *batch,