netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yojana Mallik <y-mallik@ti.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: <schnelle@linux.ibm.com>, <wsa+renesas@sang-engineering.com>,
	<diogo.ivo@siemens.com>, <rdunlap@infradead.org>,
	<horms@kernel.org>, <vigneshr@ti.com>, <rogerq@ti.com>,
	<danishanwar@ti.com>, <pabeni@redhat.com>, <kuba@kernel.org>,
	<edumazet@google.com>, <davem@davemloft.net>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<srk@ti.com>, <rogerq@kernel.org>,
	Siddharth Vadapalli <s-vadapalli@ti.com>, <y-mallik@ti.com>
Subject: Re: [PATCH net-next v2 2/3] net: ethernet: ti: Register the RPMsg driver as network device
Date: Wed, 12 Jun 2024 18:19:53 +0530	[thread overview]
Message-ID: <ebbd1bcc-ecc4-4bbe-aefb-39256abeed21@ti.com> (raw)
In-Reply-To: <bad12a9c-533e-47c3-9aa7-1a4d71eb6d87@lunn.ch>



On 6/4/24 18:30, Andrew Lunn wrote:
>>> Also, why SET_MAC_ADDR? It would be good to document where the MAC
>>> address are coming from. And what address this is setting.
>>>
>>
>> The interface which is controlled by Linux and interacting with the R5 core is
>> assigned mac address 00:00:00:00:00:00 by default. To ensure reliable
>> communication and compliance with network standards a different MAC address is
>> set for this interface using icve_set_mac_address.
> 
> So this is the peer telling the Linux machine what MAC address to use?
> As i said, it is not clear what direction this message is flowing. Or
> even if it can be used the other way around. Can Linux tell the peer
> what address it should use?
> 

No, RTOS the peer is not telling the Linux machine what MAC address to use. The
user can add a unicast mac address to the virtual network interface using the
following steps:

Steps to add MAC Address
# Bring down the virtual port interface
$ ifconfig eth1 down
# Set MAC address for the virtual port interface, ex 01:02:03:04:05:06
$ ifconfig eth1 hw ether 01:02:03:04:05:06
# Bring the interface up
$ ifconfig eth1 up

These commands will call the net_device_ops
.ndo_stop = icve_ndo_stop
.ndo_set_mac_address = icve_set_mac_address
.ndo_open = icve_ndo_open,

While adidng the mac address, ndo ops will call set_mac_address which will call
create_send_request which will create a request with command add mac address
and send a rpmsg to R5 core.


> Also, what is the big picture here. Is this purely a point to point
> link? There is no intention that one or both ends could bridge packets
> to another network? Does this link always carrier IP? If so, why do
> you need the Ethernet header? Why not just do the same as SLIP, PPP,
> other point to point network protocols.
> 
> 	Andrew

We want the shared memory to be accessed by 2 cores only. So the inter-core
virtual ethernet driver is indeed a point to point link. There is a bridging
application in R5 core. If there is a cluster of cores like multiple A53 cores
and R5 cores, and one A53 core has to send packets to another A53 core then the
A53 core can send packets to R5 core using a icve a virtual driver and R5 core
can transmit these packets to the other A53 core using another instance of icve
virtual driver. Multiple instances of virtual driver are used by the bridging
application but the virtual driver by itself is a point to point link.

The goal of the inter-core virtual ethernet driver is network traffic
tunneling between heterogeneous processors. R5 core will send ethernet packets
to Linux because R5 core wants Linux to process the ethernet packets further.
It is intended that R5 core should use resources for other processes and A53
core should use resources to take actions on the Ethernet packet. How A53 core
handles the ethernet packets depends on the ethernet header. Hence it is
necessary for the A53 core to receive ethernet header.

Regards,
Yojana Mallik


  reply	other threads:[~2024-06-12 12:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31  6:40 [PATCH net-next v2 0/3] Introducing Intercore Virtual Ethernet (ICVE) driver Yojana Mallik
2024-05-31  6:40 ` [PATCH net-next v2 1/3] net: ethernet: ti: RPMsg based shared memory ethernet driver Yojana Mallik
2024-05-31 15:30   ` Randy Dunlap
2024-06-03  5:50     ` Yojana Mallik
2024-06-02  7:01   ` Siddharth Vadapalli
2024-06-03  6:16     ` Yojana Mallik
2024-06-02 16:21   ` Andrew Lunn
2024-06-03  8:56     ` Yojana Mallik
2024-06-03 12:54       ` Andrew Lunn
2024-05-31  6:40 ` [PATCH net-next v2 2/3] net: ethernet: ti: Register the RPMsg driver as network device Yojana Mallik
2024-06-01  3:13   ` kernel test robot
2024-06-03  9:26     ` Yojana Mallik
2024-06-02  7:22   ` Siddharth Vadapalli
2024-06-02 15:54     ` Andrew Lunn
2024-06-02  7:35   ` Siddharth Vadapalli
2024-06-02 16:45   ` Andrew Lunn
2024-06-04  6:23     ` Yojana Mallik
2024-06-04 12:54       ` Andrew Lunn
2024-06-12 12:52         ` Yojana Mallik
2024-06-12 14:59           ` Andrew Lunn
2024-06-14  9:08             ` Yojana Mallik
2024-06-16 16:19               ` Andrew Lunn
2024-06-16 19:03                 ` Andrew Lunn
2024-06-04 13:00       ` Andrew Lunn
2024-06-12 12:49         ` Yojana Mallik [this message]
2024-06-12 14:36           ` Andrew Lunn
2024-05-31  6:40 ` [PATCH net-next v2 3/3] net: ethernet: ti: icve: Add support for multicast filtering Yojana Mallik
2024-06-03 21:27   ` kernel test robot
2024-06-02 15:45 ` [PATCH net-next v2 0/3] Introducing Intercore Virtual Ethernet (ICVE) driver Andrew Lunn
2024-06-03 23:54   ` Jakub Kicinski
2024-06-12 12:48   ` Yojana Mallik

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=ebbd1bcc-ecc4-4bbe-aefb-39256abeed21@ti.com \
    --to=y-mallik@ti.com \
    --cc=andrew@lunn.ch \
    --cc=danishanwar@ti.com \
    --cc=davem@davemloft.net \
    --cc=diogo.ivo@siemens.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=rogerq@kernel.org \
    --cc=rogerq@ti.com \
    --cc=s-vadapalli@ti.com \
    --cc=schnelle@linux.ibm.com \
    --cc=srk@ti.com \
    --cc=vigneshr@ti.com \
    --cc=wsa+renesas@sang-engineering.com \
    /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;
as well as URLs for NNTP newsgroup(s).