public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Vyacheslav V. Mitrofanov" <v.v.mitrofanov@yadro.com>
To: "u-boot@lists.denx.de" <u-boot@lists.denx.de>,
	"seanedmond@linux.microsoft.com" <seanedmond@linux.microsoft.com>
Cc: "trini@konsulko.com" <trini@konsulko.com>,
	"joe.hershberger@ni.com" <joe.hershberger@ni.com>,
	"rfried.dev@gmail.com" <rfried.dev@gmail.com>,
	"saproj@gmail.com" <saproj@gmail.com>,
	"seanedmond@microsoft.com" <seanedmond@microsoft.com>
Subject: Re: [PATCH] Fix neighbor discovery ethernet address saving
Date: Mon, 13 May 2024 06:55:23 +0000	[thread overview]
Message-ID: <d8017b043ae127bdd3fa4b3edf61ba8454d3d8f2.camel@yadro.com> (raw)
In-Reply-To: <9f6ea33b-9bdb-49a3-b8a6-51072d3b1a34@linux.microsoft.com>

Hello, Sean. 
I see. You are right.

Reviewed-by: Viacheslav Mitrofanov <v.v.mitrofanov@yadro.com>


On Tue, 2024-05-07 at 22:16 -0700, Sean Edmond wrote:
> 
> Hi Vyachesla,
> 
> Let's start by saying neighbour discovery protocol is definitely
> working
> properly.  I'm only suggesting that it isn't properly caching the MAC
> address.  During IPv6 TFTP I observe that neighbour discovery is
> performed before every packet sent from client(u-boot)->server.
> 
> Here's a snapshot of what the packets from client(u-boot)<->server
> look
> like during IPv6 TFTP:
> -> neighbour solicitation
> <- neighbour advertisement
> -> read request
> <- Block 0
> -> neighbour solicitation
> <- neighbour advertisement
> -> ACK block 0
> <- Block 1
> -> neighbour solicitation
> <- neighbour advertisement
> -> ACK block 1
> - ... (continues for entire file transfer)
> 
> The neighbour discovery on every TX TFTP packet isn't required and
> results in degraded performance.  Note, when performing the test with
> IPv4, ARP is not performed before every TX packet.
> 
> Here's a description of the code flow (including my proposal):
> - net.c defines "u8 net_server_ethaddr[6];"
> - tftp_send()-> net_send_udp_packet6(net_server_ethaddr, ...)
> - in net_send_udp_packet6(), "net_nd_packet_mac = ether;"  (now,
> net_nd_packet_mac is pointing to net_server_ethaddr)
> - in ndisc_receive(), when NA is received the mac becomes available
> in
> neigh_eth_addr
> - My proposal is, "if pointer net_nd_packet_mac isn't NULL, copy this
> contents of neigh_eth_addr into net_nd_packet_mac"
> - For TFTP, my fix allows the server's MAC to get copied into
> net_server_ethaddr
> - on the next tftp_send(), in net_send_udp_packet6() neighbour
> discovery
> is skipped because "ether" isn't all zeros
> 
> The memcpy isn't dangerous, because it's copying the discovered mac
> address into the already allocated net_server_ethaddr (and it's
> checking
> to make sure that net_nd_packet_mac isn't NULL before copying).
> 
> Also, the current code serves no purpose.  The current code is, "if
> net_nd_packet_mac is NULL, set it to stack variable neigh_eth_addr,
> then
> set net_nd_packet_mac to NULL when there is no ND pending (the mac
> address doesn't get saved in net_server_ethaddr).
> 
> Sean
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 2024-05-05 2:40 a.m., Vyacheslav V. Mitrofanov wrote:
> > On Mon, 2024-04-29 at 11:51 -0700, seanedmond@linux.microsoft.com
> > wrote:
> > > soc@yadro.com<mailto:soc@yadro.com>
> > > 
> > > From: Sean Edmond <seanedmond@microsoft.com>
> > > 
> > > When a successful neighbor advertisement is received, the
> > > ethernet
> > > address should be saved for later use to avoid having to redo the
> > > neighbor discovery process.
> > > 
> > > For example, with TFTP the address should get saved into
> > > "net_server_ethaddr".  This is being done correctly with ARP for
> > > IPv4,
> > > but not for neighbor discovery with IPv6.
> > > 
> > > Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
> > > ---
> > >   net/ndisc.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/net/ndisc.c b/net/ndisc.c
> > > index d1cec0601c8..505515f2d95 100644
> > > --- a/net/ndisc.c
> > > +++ b/net/ndisc.c
> > > @@ -461,8 +461,8 @@ int ndisc_receive(struct ethernet_hdr *et,
> > > struct
> > > ip6_hdr *ip6, int len)
> > >                          ndisc_extract_enetaddr(ndisc,
> > > neigh_eth_addr);
> > > 
> > >                          /* save address for later use */
> > > -                       if (!net_nd_packet_mac)
> > > -                               net_nd_packet_mac =
> > > neigh_eth_addr;
> > > +                       if (net_nd_packet_mac)
> > > +                               memcpy(net_nd_packet_mac,
> > > neigh_eth_addr, 6);
> > > 
> > >                          /* modify header, and transmit it */
> > >                          memcpy(((struct ethernet_hdr
> > > *)net_nd_tx_packet)->et_dest,
> > > --
> > > 2.42.0
> > > 
> > Hello, Sean. Thanks for your notice. I see that net_nd_packet_mac
> > is
> > just a uchar pointer without memory allocation. It is dangerous to
> > do
> > memcpy and not necessary. All works as it has to be.


  reply	other threads:[~2024-05-13  6:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29 18:51 [PATCH] Fix neighbor discovery ethernet address saving seanedmond
2024-05-05  9:40 ` Vyacheslav V. Mitrofanov
2024-05-08  5:16   ` Sean Edmond
2024-05-13  6:55     ` Vyacheslav V. Mitrofanov [this message]
2025-01-01 20:41 ` Tom Rini

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=d8017b043ae127bdd3fa4b3edf61ba8454d3d8f2.camel@yadro.com \
    --to=v.v.mitrofanov@yadro.com \
    --cc=joe.hershberger@ni.com \
    --cc=rfried.dev@gmail.com \
    --cc=saproj@gmail.com \
    --cc=seanedmond@linux.microsoft.com \
    --cc=seanedmond@microsoft.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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