Ganesh:
On 6/4/18 9:03 AM, AMG Zollner Robert wrote:
> I have noticed that vrf is not working with kernel v4.15.0 but was
> working with v4.13.0 when using cxgb4 Chelsio driver (T520-cr)
>
> Setup:
> Two metal servers with a T520-cr card each, directly connected without a
> switch in between.
>
On Sat, Jun 09, 2018 at 10:35:48PM +, Fu, Qiaobin wrote:
...
> @@ -73,6 +100,7 @@ static int tcf_skbedit_init(struct net *net, struct nlattr
> *nla,
> struct tc_skbedit *parm;
> struct tcf_skbedit *d;
> u32 flags = 0, *priority = NULL, *mark = NULL, *mask = NULL;
> + u64
The new action inheritdsfield copies the field DS of
IPv4 and IPv6 packets into skb->priority. This enables
later classification of packets based on the DS field.
v2:
*Use optional flags, so that it won't break old versions of tc.
Original idea by Jamal Hadi Salim
Signed-off-by: Qiaobin Fu
The new action inheritdsfield copies the field DS of
IPv4 and IPv6 packets into skb->priority. This enables
later classification of packets based on the DS field.
v3:
*Use optional flags, so that it won't break old versions of tc.
*Allow users to set both SKBEDIT_F_PRIORITY and
On 06/08/2018 08:06 AM, John Fastabend wrote:
> Per the note in the TLS ULP (which is actually a generic statement
> regarding ULPs)
>
> /* The TLS ulp is currently supported only for TCP sockets
> * in ESTABLISHED state.
> * Supporting sockets in LISTEN state will require us
> * to modify
Hi John,
On 06/08/2018 05:06 PM, John Fastabend wrote:
> Per the note in the TLS ULP (which is actually a generic statement
> regarding ULPs)
>
> /* The TLS ulp is currently supported only for TCP sockets
> * in ESTABLISHED state.
> * Supporting sockets in LISTEN state will require us
> *
Alexander Aring wrote:
> Futhermore user space programs e.g. radvd will do 6lowpan specific
> handling on 6lowpan dev->type, it will not work either on tun
> devices.
> I know that wpantund from NestLabs do this switch, I am very
> curious about the reason but I think they
thanks, I will test it on Monday.
Just a question for my knowledge: is the new sysfs attribute really
needed? I mean, is there not any other way to understand from qmi_wwan
without user intervention that there is the rmnet device attached?
Regards,
Daniele
Hi Daniele
You can check for the
Hi,
On Fri, Jun 08, 2018 at 03:37:44PM -0400, Michael Richardson wrote:
>
> Alexander Aring wrote:
> Alex> I already see code outside who changed tun netdevice to the
> Alex> ARPHRD_6LOWPAN type and I suppose they running into this
> Alex> issue. (Btw: I don't know why somebody
> It seems that this is going to be 100Base-T1 mess while IEEE 802.3bw
> miss Clause 22 updates. Clause 45 is rarely used from my experience. Probably
> IEEE expected 100Base-T1 PHYs to go for Clause 45 MDIO and this did not work
> so far.
Hi Kirill
Thanks for this information. So lets forget
Current generic PHY driver does not work with TJA1100 BroadR-REACH PHY
properly. TJA1100 does not have any standard ability enabled at MII_BMSR
register. Instead it has BroadR-REACH ability at MII_ESTATUS enabled, which
is not handled by generic driver yet. Therefore generic driver is unable to
Hi Subash,
2018-06-09 4:19 GMT+02:00 Subash Abhinov Kasiviswanathan
:
>> This sounds like a good idea. I probably won't have any time to look at
>> this in the near future, though. Sorry about that. Extremely overloaded
>> both at work and private right now...
>>
>> But I trust that you and
Hi Andrew.
Thanks for your comments. I will update the patch a bit later.
>
> Does 100Base-T1/cause 96 define a way to identify a PHY which
> implements this? I'm just wondering if we can do this in the generic
> code, for devices which correctly implement the standard?
>
Well, I did research
13 matches
Mail list logo
