On Thu, Apr 18, 2019 at 04:06:31PM +0200, David Marchand wrote:
> Hey Adrien,
Hey David!
> On Thu, Apr 18, 2019 at 3:12 PM Adrien Mazarguil
> wrote:
>
> > When passed to the application, Rx packets retain the port ID value
> > originally set by slave devices. Unfortunately these IDs have no mea
On Thu, Apr 18, 2019 at 03:42:24PM +0100, Ferruh Yigit wrote:
> On 4/18/2019 2:11 PM, Adrien Mazarguil wrote:
> > When passed to the application, Rx packets retain the port ID value
> > originally set by slave devices. Unfortunately these IDs have no meaning to
> > applications, which are typically
On 4/18/2019 2:11 PM, Adrien Mazarguil wrote:
> When passed to the application, Rx packets retain the port ID value
> originally set by slave devices. Unfortunately these IDs have no meaning to
> applications, which are typically unaware of their existence.
>
> This confuses those caring about the
On Thu, Apr 18, 2019 at 03:11:26PM +0200, Adrien Mazarguil wrote:
> When passed to the application, Rx packets retain the port ID value
> originally set by slave devices. Unfortunately these IDs have no meaning to
> applications, which are typically unaware of their existence.
>
> This confuses th
Hey Adrien,
On Thu, Apr 18, 2019 at 3:12 PM Adrien Mazarguil
wrote:
> When passed to the application, Rx packets retain the port ID value
> originally set by slave devices. Unfortunately these IDs have no meaning to
> applications, which are typically unaware of their existence.
>
> This confuse
When passed to the application, Rx packets retain the port ID value
originally set by slave devices. Unfortunately these IDs have no meaning to
applications, which are typically unaware of their existence.
This confuses those caring about the source port field in mbufs (m->port)
which experience i
6 matches
Mail list logo
