> -Original Message-
> From: Stephen Hemminger
> Sent: Wednesday, 27 April 2022 22:15
> To: Ido Goshen
> Cc: Ferruh Yigit ; dev@dpdk.org; Danny Raveh
>
> Subject: Re: [PATCH] net/pcap: support MTU set
>
> >
> > [idog]
> > The main use case
Support rte_eth_dev_set_mtu by pcap vdevs
Enforce mtu on rx/tx
Bugzilla ID: 961
Signed-off-by: Ido Goshen
---
v2:
preserve pcap behavior to support max size packets by default
---
drivers/net/pcap/pcap_ethdev.c | 35 +++---
lib/ethdev/rte_ethdev.c| 3
> -Original Message-
> From: Ido Goshen
> Sent: Monday, 23 May 2022 17:27
> To: Thomas Monjalon ; Ferruh Yigit
> ; Andrew Rybchenko
>
> Cc: dev@dpdk.org; Ido Goshen
> Subject: [PATCH v2] pcap: support MTU set
> v2:
> preserve pcap behavior to suppo
Support rte_eth_dev_set_mtu by pcap vdevs
Enforce mtu on rx/tx
Bugzilla ID: 961
Signed-off-by: Ido Goshen
---
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case
> -Original Message-
> From: Ferruh Yigit
> Sent: Monday, 30 May 2022 21:06
> To: Ido Goshen ; ferruh.yi...@xilinx.com;
> step...@networkplumber.org
> Cc: dev@dpdk.org; Tianli Lai
> Subject: Re: [PATCH v3] pcap: support MTU set
>
> On 5/30/2022 11:36 AM, Id
> -Original Message-
> From: Ferruh Yigit
> Sent: Monday, 30 May 2022 21:06
> To: Ido Goshen ; ferruh.yi...@xilinx.com;
> step...@networkplumber.org
> Cc: dev@dpdk.org; Tianli Lai
> Subject: Re: [PATCH v3] pcap: support MTU set
>
> On 5/30/2022 11:36 AM, Id
Support rte_eth_dev_set_mtu by pcap vdevs
Enforce mtu on rx/tx
Bugzilla ID: 961
Signed-off-by: Ido Goshen
---
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
> -Original Message-
> From: Stephen Hemminger
> Sent: Monday, 6 June 2022 20:10
> To: Ido Goshen
> Cc: ferruh.yi...@xilinx.com; dev@dpdk.org
> Subject: Re: [PATCH v4] pcap: support MTU set
>
> On Mon, 6 Jun 2022 19:21:47 +0300
> Ido Goshen wrote:
>
&
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
Bugzilla ID: 961
Signed-off-by: Ido Goshen
---
v5:
Alternative approach
Instead of checking MTU in th
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
Bugzilla ID: 961
Signed-off-by: Ido Goshen
---
v6:
Fixes for v5 approach
1. freebsd compilation
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
patch series:
[PATCH v7 1/3] pcap: support MTU set for linux interfaces
[PATCH v7 2/3] pcap: support MTU set fo
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
Bugzilla ID: 961
Signed-off-by: Ido Goshen
---
doc/guides/rel_notes/release_22_07.rst | 3 ++
driver
Drop only the oversized packets and not its entrie burst
mbuf will be freed and will be counted as oerror
Signed-off-by: Ido Goshen
---
drivers/net/pcap/pcap_ethdev.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap
Count oversized packets that are dropped by the interface
Signed-off-by: Ido Goshen
---
drivers/net/pcap/pcap_ethdev.c | 74 +-
1 file changed, 45 insertions(+), 29 deletions(-)
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
Bugzilla ID: 961
Signed-off-by: Ido Goshen
---
doc/guides/rel_notes/release_22_07.rst | 3 ++
driver
Drop only the oversized packets and not its entire burst
mbuf will be freed and will be counted as oerror
Signed-off-by: Ido Goshen
---
drivers/net/pcap/pcap_ethdev.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
patch series:
[PATCH v8 1/3] pcap: support MTU set for linux interfaces
[PATCH v8 2/3] pcap: support MTU set fo
Count oversized packets that are dropped by the interface
Signed-off-by: Ido Goshen
---
drivers/net/pcap/pcap_ethdev.c | 74 +-
1 file changed, 45 insertions(+), 29 deletions(-)
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index
> -Original Message-
> From: Stephen Hemminger
> Sent: Tuesday, 21 June 2022 1:53
> To: Ido Goshen
> Cc: ferruh.yi...@xilinx.com; dev@dpdk.org
> Subject: Re: [PATCH v7 2/3] pcap: support MTU set for linux interfaces TX
> enhancment
>
> On Sun, 19 Jun 2022
> From: Ferruh Yigit
> Sent: Tuesday, 26 April 2022 20:04
>
> On 3/22/2022 1:02 PM, Ido Goshen wrote:
> > This test
> > https://doc.dpdk.org/dts/test_plans/jumboframes_test_plan.html#test-ca
> > se-jumbo-frames-with-no-jumbo-frame-support fails for pcap pmd Ju
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Tuesday, 26 April 2022 20:57
> To: Ido Goshen ; us...@dpdk.org;
> dev@dpdk.org
> Cc: Konstantin Ananyev
> Subject: RE: Does ACL support field size of 8 bytes?
>
>
> Hi Ido,
>
> > I'v
Tested-by: Ido Goshen
> -Original Message-
> From: Konstantin Ananyev
> Sent: Sunday, 15 May 2022 23:03
> To: dev@dpdk.org
> Cc: Ido Goshen ; sta...@dpdk.org
> Subject: [PATCH v2 1/2] acl: fix rules with 8 bytes field size are broken
>
> In theory ACL library al
> -Original Message-
> From: Konstantin Ananyev
> Sent: Sunday, 15 May 2022 23:54
> To: Ido Goshen ; Ananyev, Konstantin
> ; us...@dpdk.org; dev@dpdk.org
> Subject: Re: Does ACL support field size of 8 bytes?
>
>
> My concern was it is sort of awkward in ter
cover/20220620083944.51517-1-...@cgstowernetworks.com/
It was pretty long ago - not sure which is in favor
> -Original Message-
> From: Stephen Hemminger
> Sent: Wednesday, 5 July 2023 18:19
> To: Ferruh Yigit
> Cc: dev@dpdk.org; Ido Goshen
> Subject: Re: [PATCH v2] pcap:
uh Yigit
> Sent: Monday, 10 July 2023 20:47
> To: Stephen Hemminger ; Ido Goshen
>
> Cc: Ferruh Yigit ; dev@dpdk.org
> Subject: Re: [PATCH] net/pcap: support MTU set
>
> On 7/10/2023 5:45 PM, Stephen Hemminger wrote:
> > On Thu, 17 Mar 2022 19:43:47 +0200
> > ido g wr
s.dpdk.org/show_bug.cgi?id=961
> -Original Message-
> From: Stephen Hemminger
> Sent: Thursday, 17 March 2022 20:21
> To: Ido Goshen
> Cc: Ferruh Yigit ; dev@dpdk.org
> Subject: Re: [PATCH] net/pcap: support MTU set
>
> On Thu, 17 Mar 2022 19:43:47 +0200
>
#######
> -Original Message-
> From: Ido Goshen
> Sent: Thursday, 17 March 2022 21:12
> To: Stephen Hemminger
> Cc: Ferruh Yigit ; dev@dpdk.org
> Subject: RE: [PATCH] net/pcap: support MTU set
>
> As far as I can see the initial device MTU is derived from po
From: Ido Goshen
10BASE-T SFP+ copper transceivers become cheaper and popular
So far those were blocked by ixgbe as “unsupported”.
e.g.
eth_ixgbe_dev_init(): Unsupported SFP+ Module
eth_ixgbe_dev_init(): Hardware Initialization Failure: -19
EAL: Requested device :0a
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Wednesday, April 24, 2019 2:47 PM
> To: Ido Goshen ; Lu, Wenzhuo
>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH] net/ixgbe: 10GBASE-T SFP+ copper support
>
>
>
> >
> > From: Ido Goshen
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Friday, April 26, 2019 3:13 PM
> To: Ido Goshen ; Lu, Wenzhuo
>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH] net/ixgbe: 10GBASE-T SFP+ copper support
>
>
>
> > > > From: Ido Go
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, May 2, 2019 2:41 AM
> To: Ido Goshen ; Lu, Wenzhuo
>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH] net/ixgbe: 10GBASE-T SFP+ copper support
>
>
>
> > -----Original Message
> -Original Message-
> From: Stillwell Jr, Paul M
> Sent: Wednesday, May 8, 2019 1:46 AM
> To: Igor Russkikh ; Ido Goshen
> ; Ananyev, Konstantin
> ; Lu, Wenzhuo
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: 10GBASE-T SFP+ copper support
Signed-off-by: Ido Goshen
---
drivers/net/pcap/rte_eth_pcap.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index a32b1f3f3..83e208514 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap
Signed-off-by: Ido Goshen
---
v2:
* sum all queues (rx_missed_total += fix)
* null pcap protection
* inter stop/start persistancy (counter won't reset on stop)
drivers/net/pcap/rte_eth_pcap.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/net
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, 28 January 2021 20:21
> To: Ido Goshen
> Cc: dev@dpdk.org
> Subject: Re: [PATCH 1/1] net/pcap: imissed stats support
>
> On 1/25/2021 5:58 PM, Ido Goshen wrote:
> > Signed-off-by: Ido Goshe
> -Original Message-
> From: Ferruh Yigit
> Sent: Monday, 1 February 2021 13:49
> To: Ido Goshen
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v2] net/pcap: imissed stats support
>
> On 2/1/2021 8:30 AM, Ido Goshen wrote:
> > Signed-off-by: Ido Goshen
> &
get value from pcap_stats.ps_drop (see man pcap_stats)
the value is adjusted in this cases:
- port stop - pcap is closed and will lose count
- stats reset - pcap doesn't provide reset api
- rollover - pcap counter size is u_32 only
Signed-off-by: Ido Goshen
---
v3:
* code cleanup by dedi
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, 4 February 2021 2:13
> To: Ido Goshen
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v3 1/1] net/pcap: imissed stats support
>
> On 2/3/2021 11:07 PM, Ido Goshen wrote:
> > get value from pcap_stats.ps
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, 4 February 2021 11:26
> To: Ido Goshen
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v3 1/1] net/pcap: imissed stats support
>
> On 2/4/2021 7:56 AM, Ido Goshen wrote:
> >
> >
> >>
get value from pcap_stats.ps_drop (see man pcap_stats)
the value is adjusted in this cases:
- port stop - pcap is closed and will lose count
- stats reset - pcap doesn't provide reset api
- rollover - pcap counter size is u_32 only
Signed-off-by: Ido Goshen
---
v4:
* remove volatile
*
> -Original Message-
> From: Ferruh Yigit
> Sent: Wednesday, June 27, 2018 4:59 PM
> To: Ido Goshen ; Bruce Richardson
> ; John McNamara
> ; Marko Kovacevic
>
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v3] net/pcap: rx_iface_in stream type support
>
>
From: ido g
Support rx of in direction packets only
Useful for apps that also tx to eth_pcap ports in order to not see them
echoed back in as rx when out direction is also captured
Example:
In case using rx_iface and sending *single* packet to eth1
it will loop forever as the when it is sent to
Support rx of in direction packets only
Useful for apps that also tx to eth_pcap ports in order not to see them
echoed back in as rx when out direction is also captured
Signed-off-by: ido goshen
---
drivers/net/pcap/rte_eth_pcap.c | 34 +++---
1 file changed, 31
ackets received: 1
Total packets dropped: 0
-Original Message-
From: Ferruh Yigit
Sent: Tuesday, June 5, 2018 4:27 PM
To: Ido Goshen
Cc: dev@dpdk.org
Subject: Re: [PATCH v2] net/pcap: rx_iface_in stre
Support rx of in direction packets only
Useful for apps that also tx to eth_pcap ports in order not to see them
echoed back in as rx when out direction is also captured
Signed-off-by: ido goshen
---
v2: clean checkpatch warning
drivers/net/pcap/rte_eth_pcap.c | 36
om far end to eth0 ip)
-Original Message-----
From: Ferruh Yigit
Sent: Wednesday, June 13, 2018 1:57 PM
To: Ido Goshen
Cc: dev@dpdk.org
Subject: Re: [PATCH v2] net/pcap: rx_iface_in stream type support
On 6/5/2018 6:10 PM, Ido Goshen wrote:
> The problem is if a dpdk app uses the sam
essage-
From: Ferruh Yigit
Sent: Thursday, June 14, 2018 9:09 PM
To: Ido Goshen
Cc: dev@dpdk.org
Subject: Re: [PATCH v2] net/pcap: rx_iface_in stream type support
On 6/14/2018 6:14 PM, Ido Goshen wrote:
> I use "rx_iface","tx_iface" (and not just "iface")
evice (or some
networking trick) to send packets to the app.
So, I'd say it is good for testing but less good for real functionality
-Original Message-----
From: Ferruh Yigit
Sent: Friday, June 15, 2018 3:53 PM
To: Ido Goshen
Cc: dev@dpdk.org
Subject: Re: [PATCH v2] net/pcap: rx_ifac
Signed-off-by: ido goshen
---
drivers/net/pcap/rte_eth_pcap.c | 58 -
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 444abbb..e63998b 100644
--- a/drivers/net/pcap
en by
the sequential calls to open_rx/tx_pcap/iface functions
3. Use the filename/iface args per queue and not just the last one
that overwrites the previous names
Signed-off-by: ido goshen
---
drivers/net/pcap/rte_eth_pcap.c | 85 +
1 file change
s.
If pcap_sendpacket to the same pcap_t handle is not thread safe then it will
require to pcap_open_live() for each queue
If using multiple pcap_open_live() then it will cause the rx out direction
problem again
-Original Message-
From: Ferruh Yigit
Sent: Monday, June 18, 2018 11:13 AM
To: Ido G
See Inline prefixed with [ido]
-Original Message-
From: Ferruh Yigit
Sent: Monday, June 18, 2018 11:25 AM
To: Ido Goshen
Cc: dev@dpdk.org
Subject: Re: [PATCH 1/2] net/pcap: multiple queues fix
On 6/16/2018 4:36 PM, ido goshen wrote:
> Change open_rx/tx_pcap/iface functions to o
rs instead of N^2
2. Leak of pcap/dumper's which are being overwritten by
the sequential calls to open_rx/tx_pcap/iface functions
3. Use the filename/iface args per queue and not just the last one
that overwrites the previous names
Signed-off-by: ido goshen
---
v2:
* fix num of queues che
Signed-off-by: ido goshen
---
drivers/net/pcap/rte_eth_pcap.c | 77 +
1 file changed, 40 insertions(+), 37 deletions(-)
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index b4f81ac..b21930b 100644
--- a/drivers/net/pcap
Suggested-by: Ferruh Yigit
Signed-off-by: ido goshen
---
drivers/net/pcap/rte_eth_pcap.c | 82 +
1 file changed, 50 insertions(+), 32 deletions(-)
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index b21930b..33c5366
day, June 20, 2018 8:41 PM
To: Ido Goshen
Cc: dev@dpdk.org
Subject: Re: [PATCH v2 2/2] net/pcap: duplicate code consolidation
On 6/19/2018 3:37 PM, ido goshen wrote:
> Signed-off-by: ido goshen
<...>
> /*
> + * Opens a NIC for reading packets from it */ static inline int
>
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, June 21, 2018 3:51 PM
> To: Ido Goshen
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v2 3/3] net/pcap: support pcap files and ifaces mix
>
> On 6/21/2018 1:24 PM, ido goshen wrote:
> > Suggested-by
I guess the error below relates to f52f1a6 ethdev: force offloading API rules
cgs@ubuntu:~/dpdk-next-net$ sudo examples/l2fwd/build/l2fwd -c 3 -n1 --no-huge
--vdev=eth_pcap0,iface=dummy0 --vdev=eth_pcap1,iface=dummy1 -- -p 3 -T 1
EAL: Detected 4 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-pro
From: ido g
Support rx of in direction packets only
Useful for apps that also tx to eth_pcap ports in order to not see them
echoed back in as rx when out direction is also captured
Signed-off-by: ido g
---
v3:
* merge to updated dpdk-next-net code
* pcap_ring doc update
v2:
* clean checkpatch
59 matches
Mail list logo
