On 12/1/21 21:51, Martin KaFai Lau wrote:

On Wed, Dec 01, 2021 at 08:15:28PM +0000, Pavel Begunkov wrote:

quoted

On 12/1/21 19:20, David Ahern wrote:

quoted

On 12/1/21 12:11 PM, Pavel Begunkov wrote:

quoted

btw, why a dummy device would ever go through loopback? It doesn't
seem to make sense, though may be missing something.

You are sending to a local ip address, so the fib_lookup returns
RTN_LOCAL. The code makes dev_out the loopback:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/net/ipv4/route.c#n2773

I see, thanks. I still don't use the skb_orphan_frags_rx() hack
and it doesn't go through the loopback (for my dummy tests), just
dummy_xmit() and no mention of loopback in perf data, see the
flamegraph. Don't know what is the catch.

I'm illiterate of the routing paths. Can it be related to
the "ip route add"? How do you get an ipv4 address for the device?

I also bumped into the udp-connect() => ECONNREFUSED (111) error from send-zc.
because I assumed no server is needed by using dummy.  Then realized
the cover letter mentioned msg_zerocopy is used as the server.
Mentioning just in case someone hits it also.

To tx out dummy, I did:
#> ip a add 10.0.0.1/24 dev dummy0

Works well for me, IOW getting the same behaviour as with my
ip route add <ip> dev dummy0

I'm curious what is the difference bw them?

#> ip -4 r
10.0.0.0/24 dev dummy0 proto kernel scope link src 10.0.0.1

#> ./send-zc -4 -D 10.0.0.(2) -t 10 udp
ip -s link show dev dummy0
2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 65535 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 82:0f:e0:dc:f7:e6 brd ff:ff:ff:ff:ff:ff
    RX:    bytes packets errors dropped  missed   mcast
               0       0      0       0       0       0
    TX:    bytes packets errors dropped carrier collsns
    140800890299 2150397      0       0       0       0

-- 
Pavel Begunkov